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CHAPTER  I 
Introduction 


The  degree  of  sophistication  in  today's  computer  systems  is  a  far  cry 
from  those  programmable  numerical  integrating  devices  of  yesteryear.  The 
advances  in  hardware  capabilities  and  complexity  necessitate  some  form  of 
automated  procedures  in  operating  them.  These  automated  procedures  are 
implemented  in  a  collection  of  programs.  We  customarily  think  of  programs 
as  software.  In  fact,  a  hard-wired  schematic  is  also  a  form  of  programming 
but  with  considerably  less  flexibility. 

Our  ideas  on  how  to  automate  the  system  operations  change  often  as  we 
learn  from  experience;  the  process  is  necessarily  an  evolutionary  one.  In 
this  light,  flexibility  is  more  than  just  a  plus;  it  is  sine  qua  non.  And 
today,  whenever  we  speak  of  operating  systems,  the  mind  immediately  conjures 
up  the  image  of  programs  —  software  programs  at  that.  This  perception  is 
not  far  off,  even  though  cases  can  be  made  where  the  operating  system  actions 
are  furnished  by  hardware.  However,  one  should  not  confuse  the  notion  of  an 
operating  system  with  that  of  system  programming;  the  latter  is  but  implemen¬ 
tation  of  the  concepts  of  the  former.  These  concepts  and  ideas  are  the  cul¬ 
mination  of  much  trial  and  error  over  the  years.  The  specific  implementations 
are  mostly  drawn  from  personal  experiences.  In  spite  of  the  constant  asso¬ 
ciation  (everyone  who  uses  computer  today  would  come  into  contact  with  an 
operating  system  of  one  form  or  another,  unless  it  is  a  more  primitive  one, 
like  a  microprocessor)  and  constant  efforts  in  this  direction  in  recent  years, 
we  still  do  not  understand  very  much  about  the  operating,  system.  Oftentimes, 
we  are  still  "amazed"  by  the  wholly  "unexpected"  change  in  system  character 
by  some  seemingly  innocent  changes  in  one  of  the  system  modules.  We  do  not 
yet  have  any  viable  "theory"  pertinent  to  the  operating  system,  and  even  its 
"principles"  are  sometimes  haphazardly  stated.  Nowhere  more  glaringly 
apparent  is  the  fact  that  the  terminologies  are  oriented  toward  specific 
system  implementation  than  uniformity.  Standardization  would  certainly  be 
the  first  step  in  the  appropriate  direction. 

Unlike  some  other  branches  of  the  system  sciences,  an  operating  system 
is  one  that  is  difficult  to  define,  and  its  design  specification  cannot  be 
quantified,  if  it  can  be  specified  at  all.  But  at  least  we  should  search 
for  some  common  rules  in  system  design  rather  than  an  implementation  based 
on  gained  experiences  or  application  requirements.  Using  this  as  a  guiding 
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principle,  our  discussions  that  follow  will  adhere  to  generality  whenever 
possible,  so  that  the  results  may  be  applicable  in  a  wide  range  of  situations. 
Specifically,  we  shall  study  the  resource  allocation  question  in  general  and 
the  memory  allocation  question  in  particular  in  a  multi-p'rogrammed  environment. 
In  carrying  on  the  discussions,  we  have  used  the  terms  program,,  job,  task, 
process  interchangeably,  whenever  the  meaning  is  clear  in  the  Context. 

In  order  to  see  where  we  might  be  going,  we  should  know  where  we  have 
been.  Chapter  2  gives  a  brief  historical  review  on  the  subject  of  operating 
systems,  dating  back  to  the  days  when  it  was  only  known  as  an  in-core  super¬ 
visor.  Although  some  of  the  important  technical  developments  were  precipi¬ 
tated  by  specific  events  or  specific  systems,  we  have  avoided  introducing 
specific  models  of  particular  manufacturers  into  the  picture.  The  continuity 
in  thought  has  not  been  compromised  by  this  approach,  we  believe. 

Chapter  3  continues  to  examine  the  modern  systems.  Out  of  many  areas  of 
system  abstractions,  we  concentrate  on  the  concurrent  processes,  queueing 
models,  and  working  set  model.  Even  though  these  three  areas  are  outwardly 
quite  different,  they  are  drawn  together  by  a  common  concern,  i.e.,  they  are 
all  related  to  system  resources;  either  they  deal  with  them  or  are  defined  by 
them,  explicitly  or  implicitly.  Finally,  the  question  of  performance  is 
re-examined  and  the  view  broadened. 

In  Chapter  A,  we  introduce  the  concept  of  activity  aggregates.  Some 
basic  properties  of  system  activities  are  postulated.  If  we  view  the  entire 
operating  system  as  being  one  which  is  a  conglomerate  of  individual  activities, 
comprised  of  both  the  system's  own  and  those  of  the  users',  and  if  the  concept 
of  computing  utility  can  be  interpreted  as  the  availability  of  a  primary 
"commodity''  for  individual  "production  needs",  then  the  function  of  an 
operating  system  becomes  a  managerial  one.  The  system  resource  allocation 
policy  becomes  that  of  determining  an  optimum  plan  for  distributing  the 
limited  resources  under  linear  constraints.  A  specific  activity,  the  memory 
allocation  activity,  is  formally  stated  in  the  context  of  Linear  Programming. 
The  Simplex  Method  for  solving  Linear  Program  Problems  is  then  briefly 
described. 

Chapter  5  probes  deeper  into  the  question  of  memory  allocation  in  the 
context  of  program  loading  (selection  from  the  system  job  queue).  Further¬ 
more,  the  result  of  this  selection  can  be  controlled  by  the  appropriate  choice 
of  an  objective  function.  A  generalized  value  concept  is  then  introduced  in 
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conjunction  with  the  formulation  of  linear  objective  functions.  This  general¬ 
ized  approach  embodies  the  priority  scheduling.  We  also  differentiate  the 
term  scheduling  from  allocation.  The  point  is  brought  into  sharper  focus  by 
discussing  a  dynamic  formulation  of  the  loading  and  executing  activities. 

While  loading  reflects  the  resource  allocation  policy,  executing  activity 
manifests  the  policy  of  scheduling. 

In  Chapter  6,  we  again  examine  the  question  of  memory  allocation  in 
a  paged  environment.  The  addressing  characteristics  of  programs  (user  pro¬ 
files)  are  discussed,  using  the  concept  of  a  Lifetime  Function  propounded 
by  Belady  and  Kuehner  as  a  vehicle.  And  the  possibility  of  using  this  Life¬ 
time  Function  characteristic  as  a  criterion  for  initial  memory  allocation 
is  explored;  an  analytic  form  of  this  function  is  suggested,  and  a  curve¬ 
fitting  procedure  is  also  proposed  for  obtaining  the  unknown  parameters  from 
measured  data  points. 

In  Chapter  7,  we  conclude  that  by  carefully  defining  the  activities 
based  on  the  concepts  set  forth  in  ChapLcr  4,  and  with  a  broadened  view  on 
performance,  general  principles  for  optimal  policies  can  be  studied  through 
the  aid  of  mathematical  programming. 


3 


CHAPTER  II 

Operating  System  in  Perspective 

2.1  Introduction 

In  this  chapter  we  will  first  trace  back  some  of  the  history  to  see  where 
it  came  from  and  how  it  came  about.  In  so  doing,  hopefully  we  can  see  where 
it  should  be  going.  Section  2  gives  a  historic  view  on  the  subject.  No 
particular  machine  will  be  mentioned,  but,  the  emphasis  is  rather  on  the 
motivation  and  the  hardware/software  interaction  which  influenced  the  conceptual 
and  technical  developments  of  what  came  to  be  regarded  as  operating  system. 
Section  3  gives  an  overview  on  the  scope  and  capabilities  of  today's  system. 
Finally,  Section  4  gives  a  brief  discussion  on  our  view;  it  is  of  a  managerial 
nature . 

2.2  Historic  View  -  A  Precis 

Ever  since  the  first  large  scale  electronic  computer,  ENLAC,  was  completed 
in  1946,  computers  have  progressed  from  programmable  calculating  devices  to  the 
myriad  of  computing  facilities  within  a  span  of  three  decades.  Certainly  the 
concept  of  a  computer  has  also  evolved  from  high  speed  (relatively  speaking) 
numerical  computational  tool  to  that  of  a  general  purpose  computing  utility. 

The  users  today  have  come  to  view  the  entire  hardware /software  complex  as  an 
"environment"  within  which  the  computational  tasks  were  carried  out.  Of  course 
it  did  not  begin  this  way;  the  early  machines  had  no  software  support  at  all. 

In  studying  the  chronology  of  electronic  computers,  the  term  "generation"  has 
been  widely  in  use  since  the  mid-60's.  Mainly,  it  is  used  to  characterize  the 
stages  of  hardware  development.  They  are  roughly  as  follows  [1]: 

First:  1946  -  1959 

Second:  1959  -  1965 

Third:  1965  -  onward 

The  above  dates  are  approximate  ones  but  there  is  little  disagreement  on 
what  belongs  to  which  generation;  for  they  are  so  divided  according  to  the 
technology  of  implementations.  Namely,  the  first  generation  was  a  vacuum  tube 
era.  The  second  generation  was  characterized  by  transistorized  logic.  Inte¬ 
grated  circuit  technology  ushered  in  the  third  generation.  However,  since  the 
announcing  of  IBM  System  370,  there  has  been  no  consensus  as  to  whether  the 
fourth  generation  has  arrived.  For  there  is  no  clean  cut  boundary,  either  in 
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terms  of  technology  or  concepts,  which  might  separate  them  from  the  third 
generation,  as  did  the  previous  ones.  In  fact,  it  is  a  system  of  evolutionary 
refinements.  Some  have  thus  labelled  the  years  from  1968  until  present  time 
as  the  late  Third  Generation. 

There  were  also  efforts  in  dividing  the  software  developments  and  systems 
into  "generations".  It  is  less  successful  because  of  the  circumstances 
surrounding  the  software  developments.  The  term  "software"  here  does  not 
refer  to  user,  or  the  so-called  application  programs.  It  is  the  facility 
with  which  programmers  can  efficiently  develop,  debug  and  execute  their  own 
programs.  Initially,  none  existed.  With  the  hardware  advances  and  therefore 
the  desire  for  their  better  utilization  and  better  service  to  users,  the 
concept  of  certain  coni. oiling  routines  evolved,  which  again  led  to  certain 
added  hardware  feature  and  improvements,  etc.  Therefore,  we  may  say  that 
software  maturity  follows  the  hardware  development  and  in  turn  acts  partially 
as  an  impetus  for  the  coming  into  being  of  a  certain  special  purpose  hardware. 
This  sort  of  "development  cycle"  is  at  least  true  for  the  earlier  generations 
of  computers. 

According  to  Rosin  [2],  there  are  periods  of  development  that  can  be 
identified  with  their  capabilities.  Chronologically,  they  are: 


Pre  -  1956: 
1956  -  1958: 
1959  -  1961: 
1962  -  1964 : 
1965  -  1968: 


Job-Bv-Job  Processing 
Early  Batch  System 
Executive  Systems 
Upgrading  and  Higher  Volume 
Re  f inement 


In  each  period,  there  were  innovations  (technical  as  well  as  conceptual) 
except,  of  course,  the  Pre-1956  days.  In  tracing  through  these  tidbits,  we 
begin  to  get  a  picture  of  the  hardware/software  interactions  behind  the 
development  forces. 

From  the  beginning,  the  majority  of  programs  were  written  in  machine  code, 
in  either  decimal  or  octal,  in  absolute  rather  than  relocatable  mode,  and 
with  no  library  routines;  or  in  a  primitive  assembly  language  which  allowed 
the  user  to  assemble  symbolic  library  routines,  provided  in  a  card  deck, 
along  with  his  program.  All  1/0  devices,  namely,  card  reader  and  line 
printer  (maybe  just  the  console  typewriter)  were  on-line.  The  user  had  to 
operate  the  computer  and  the  peripherals  himself.  Other  than  perhaps  a  self- 
loading  one-card  loader,  which  occupied  very  little  memory  space,  practically 
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all  the  information  in  memory  was  put  there  by  the  user  himself.  By  using 
the  console  switches  and  lights,  the  user  was  able  to  trace  through  and  to 
understand  precisely  the  status  of  his  program  executions.  In  a  way,  the 
user  had  complete  contact  with  the  machine. 

As  the  hardware  speed  and  cost  increased,  it  was  obvious  that  the 
previous  arrangements  were  not  desirable  from  the  economical  point  of  view. 

It  had  gotten  to  the  point  where  many  of  the  manual  procedures  took  much 
longer  time  than  the  actual  program  assembling  and  execution.  It  appeared 
that  the  multi-step  procedures  such  as  loading  an  assembler,  assembling  a 
program,  and  then  reloading  the  object  code,  could  be  automated  by  the  computer 
itself  under  the  control  of  a  specially  constructed  program.  The  advent  of 
FORTRAN  in  1957  provided  additional  motivation;  now  the  user  had  a  choice 
between  calling  either  the  assembler  or  the  FORTRAN  compiler.  The  slow  on-line 
card  reader  and  line  printer  were  circumvented  by  using  magnetic  tapes.  Jobs 
were  grouped  together  into  a  collection  called  a  batch .  The  batch  was  read 
onto  a  tape  by  an  off-line  card-to-tape  device.  A  small  controlling  program, 
called  a  monitor,  performed  the  tasks  of  sequencing  from  job  to  job,  calling 
in  various  system  components  as  needed:  assembler,  compiler,  loader  (object 
program) ,  along  with  subroutines  from  a  library  file  on  tape  and  perhaps  also 
a  post-mortem  dump  routine.  Printed  output  was  processed  from  the  output 
tape  by  an  off-line  tape-to-printing  device.  I/O  tapes  were  hand  carried. 
Whatever  special  manual  operations  or  instructions  such  as  handling  user  tapes 
were  performed  by  an  operator.  The  user,  in  general,  was  by  then  totally 
removed  from  direct  physical  contacts  with  the  computer.  Fig.  2.1  depicts 
the  structure  of  such  a  facility. 

The  assignment  of  special  tape  units  for  I/O  purposes  meant  that  there 
must  be  I/O  standardization.  Every  user  had  to  program  all  Read/Write  opera¬ 
tions  using  these  units  and  was  forbidden  to  manipulate  those  tape  units 
assigned  for  system  use.  Furthermore,  the  I/O  tapes  contained  more  than  one 
user.  Care  had  to  be  exercised  to  prevent  reading  from  the  input  tape  beyond 
one  boundary  of  one's  own  data  and  to  prevent  writing  over  someone  else's 
result  on  the  output  tape.  To  reduce  such  unhappy  occasions,  the  system 
library  also  contained  a  set  of  standard  I/O  routines  for  returning  control 
to  the  system  at  the  end  of  file  tape  mark,  and  for  requesting  a  dump  before 
signing  off.  FORTRAN  programs  had  to  use  these  routines  since  the  language 
itself  had  no  such  facilities.  To  make  it  easier  for  assembly  programs  to  use 
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these  routines  and  also  those  system  supplied  subroutines  primarily  intended 
for  FORTRAN  programs,  such  as  square  root,  etc.,  standard  subroutine  calling 
sequence  and  linkage  were  established. 

Because  of  the  increasing  flexibility  in  linking  subroutines  and  in 
order  to  make  effective  use  of  high  speed  storage  space,  all  object  programs 
were  in  relocatable  mode  rather  than  absolute.  The  loader  then  would  have  to 
link  the  collection  of  relocatable  object  programs  into  a  well  defined 
absolute  program.  Also,  the  limited  amount  of  memory  space  led  to  the  develop¬ 
ment  of  job  step  chaining  or  overlay .  Finally,  since  the  user  was  totally 
absent  from  the  machine,  and  most  of  the  activities  within  the  computer  were 
automatic,  the  on-line  printer  (or  console  typewriter)  was  assigned  the  func¬ 
tion  of  recording  the  system  log  so  that  it  at  least  provided  a  way  to  monitor 
the  behavior  of  the  system,  and  for  communicating  with  the  operator.  The 
availability  of  a  system  clock  made  it  possible  for  the  accounting  function 
to  be  partially  automated.  Many  of  the  concepts  and  techniques  developed 
in  this  period  of  early  batching  systems  really  laid  down  the  groundwork  for 
the  succeeding,  executive  systems  and  the  refinements  and  extensions  later  on. 

During  the  years  from  1959  to  1961,  certain  hardware  developments  were 
most  significant.  It  was  the  data  channel,  and  later,  the  ability  of  the 
channel  to  interrupt  main  frame  activity.  The  data  channel  was  essentially 
what  we  would  call  a  peripheral  processor  today.  Their  usage  allowed  over¬ 
lapped  I/O  and  computational  processing.  A  buffer  facility  was  used,  and  a 
wait  loop  was  needed  to  test  the  I/O  activities.  The  advent  of  I/O  comple¬ 
tion  interrupts  and  exception  operations  (end-of-f lie ,  end-of-tape,  etc.) 
allowed  fully  overlapped  I/O  buffering  without  the  wait  loop.  The  interrupt 
enabling,  masking,  and  disabling  created  a  very  complex  situation.  This 
necessitated  a  set  of  standard  I/O  request  and  interrupt  handling  routines. 

The  mandatory  usage  of  these  packages  led  to  the  establishment  of  permanently 
resident  I/O  supervisor  and  "low  core"  or  interrupt  processor.  This  created 
a  problem  in  the  area  of  protection.  There  was  no  sure  way  of  preventing 
the  resident  supervisor  being  overwritten  except  with  hardware  protection 
facilities. 

The  generality  provided  by  the  centralization  of  I/O  processing  and 
system  supervision  dictated  a  high  degree  of  modularity  in  the  overall  system 
and  its  components.  It  became  clear  that  all  system  components  should  be 
addressed  through  standard  interface  routines.  All  the  components  would 
communicate  with  each  other  using  a  fixed  communication  region.  Finally, 
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the  diversity  of  available  facilities  and  functions  demanded  the  development 
of  consistent  and  convenient  methods  for  making  use  of  the  system.  Thus  a 
command  language  evolved.  We  see  that  the  major  techniques  and  important 
concepts  had  been  developed  in  this  period  which  we  would  consider  as  the 
coming  of  the  Executive  System.  The  years  that  followed  were  essentially 
a  case  of  upgrading  and  refinement.  But  several  important  hardware  develop¬ 
ments  should  be  pointed  out.  Hardware  protection  in  the  form  of  a  program¬ 
mable  interrupting  clock  and  hardware  storage  protection  allowed  in  the 
detection  and  halting  of  an  infinite  loop  in  a  program  and  permitted  the 
integrity  of  the  resident  supervisor  to  be  guaranteed.  An  important  advance 
was  the  arrival  of  the  magnetic  disc.  With  its  relatively  short  access  time 
and  high  data  capacity,  coupled  with  the  increasingly  fast  and  larger  memory 
space,  the  impact  on  the  design  of  supervisory  systems  was  tremendous. 

2 . 3 _ Mode rn  Operating  Systems 

Whenever  we  think  of  the  modern  system,  the  mind  immediately  conjures 
up  the  image  of  a  facility  that,  with  a  combination  of  hardware  and  software, 
provides  the  user  a  great  deal  of  flexibility  in  using  it.  It  is  quite  common 
to  have  a  system  that  supports  multiprogramming,  local  and  remote  batch 
processing,  time-sharing,  extensive  file  manipulating  capability  and  on-line 
text  editing,  etc.  There  are  some  important  developments  in  system  concepts 
that  mark  it  as  state  of  the  art. 

The  provisions  for  user's  data  and  program  files  to  be  resident  in  the 
system  on  direct  access  devices,  i.e.,  drum,  disc,  and  on  sequential  devices 
such  as  magnetic  tapes,  together  with  general  accessing  routines  and  message 
generators  (for  counting  and  dismounting  instructions  to  operator)  made  it 
possible  for  users  to  build  large  and  complex  files  for  use  in  their  programs 
without  the  drudgery  of  programming  those  routines. 

In  supplementing  the  hardware  protection  facilities  discussed  above,  the 
interrupt  facilities  were  expanded  to  cover  the  execution  of  some  potentially 
dangarous  instructions  such  as:  illegal  op-code;  setting  the  internal  timer; 
setting  the  protection  register,  etc.  This  further  led  to  the  concept  of 
master/slave  mode  of  operation.  Any  interrupt  would  cause  the  hardware  to 
be  in  a  master  mode,  i.e.,  the  supervisor  will  get  control  of  the  processor. 
Thus,  the  interrupt  is  the  only  facility  with  which  a  user  can  communicate 
with  the  system  and  also,  the  only  way  for  the  supervisor  to  get  control  of 


Che  processor  back  from  the  user.  In  dividing  up  che  system  into  a  privileged 
and  an  unprivileged  class  of  operations,  the  supervisor  has  become  the  final 
arbitrator. 

In  order  to  support  more  batch  or  interactive  terminal  users,  a  paging 
scheme  was  devised.  This  came  about  from  the  observation  that  at  any  given 
time,  only  portions  of  the  program  address  space  were  needed  in  memory  to 
sustain  the  execution,  The  ability  of  a  program  to  address  a  virtual  store 
much  larger  than  a  physical  store  meant  that  additional  hardware  for  dynamic 
address  translation  and  additional  supervisor  routines  were  necessary. 

Operating  systems  have  evolved  along  with  the  increasing  sophistication 
of  hardware  capability  as  well  as  the  concept  of  computing  utility.  If, 
looking  at  them  from  the  point  of  view  of  their  characteristics,  the  present 
day  systems  have  the  following  common  properties: 

Concurrency 

Resource  allocation  (automatic) 

Resource  sharing 
Multiplexing 

Remote  access  (batch  or  conversational) 

Nondeterminacy 
Long-term  store 

These  properties  are  not  completely  independent  from  each  other;  and 
no  particular  system  need  exhibit  all  of  them.  The  advent  of  the  data  channel 
made  it  possible  to  overlap  CPU  and  I/O  processings  and  therefore  multi¬ 
programming,  If  we  look  at  a  system  with  one  CPU  and  several  channels, 
under  mult iprogram  configuration,  most  likely  there  will  be  several  processes 
being  "active  concurrently"  at  any  given  time.  Since  different  uses  present 
different  demands  on  limited  resources,  their  allocation  would  have  to  be 
automatic  and  centralized.  Not  all  physical  resources  can  be  shared  but 
there  are  non-physical  resources  in  the  form  of  system  routines,  such  as 
re-entrant  codes  and  data  files  which  are  intended  to  be  shared  with  others. 

To  accomplish  this  sharing,  the  system  must  provide  time-multiplexing,  e.g., 
the  sharing  of  CPU  in  time-sharing  system.  And  the  nondeterminacy  is  a 
necessary  consequence  of  concurrency,  sharing,  and  multiplexing.  That  is, 
the  order  in  which  resources  are  assigned,  released,  accessed,  or  shared  by 
concurrent  processes  is  unpredictable  and  the  system  routines  controlling 
these  activities  must  make  provision  for  this. 
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2.4  Summary  and  Discussion 

In  previous  sections,  we  have  pieced  together  a  view  of  the  evolution 
of  operating  systems  and  the  motivations  behind  these  developments.  The 
fact  that,  in  earlier  times,  they  were  termed  supervisor,  or  monitor,  really 
conveyed  their  intended  functions.  After  those  early  trial  days,  the  operating 
system  has  come  into  its  own  together  with  the  third  generation  hardware 
systems.  The  operating  system  has  matured  in  the  sense  that  we  pretty  much 
know  what  the  system  "should"  be  capable  of  doing  in  a  computing  facility 
and  the  technical  know-how  to  somehow  producing  it.  That  is  not  to  say  that 
we  know  how  to  make  an  operating  system  work  very  nicely.  Can  we  define  an 
Operating  System?  Denning  [3]  defined  it  through  the  functional  character¬ 
istics  of  computer  systems.  A  computer  system  has  to  perform  the  following 
seven  functions: 

1)  Creating  and  removing  processes 

2)  Controlling  the  progress  of  processes 

3)  Acting  on  exceptional  conditions  arising  during  the  execution  of  a 
process 

4)  Allocating  hardware  resources  among  processes 

5)  Providing  access  to  software  resources 

6)  Providing  protection 

7)  Interprocess  communication. 

The  system  software  that  assists  the  hardware  in  implementing  these 
functions  is  called  the  "Operating  System".  Defined  in  this  way,  an  operat¬ 
ing  system  is  being  viewed  as  the  software  complement  to  the  hardware  to  make 
a  complete  computer  system.  However,  it  does  not  have  to  be  viewed  this  way. 
There  are  certain  system  functions  which  can  be  thought  of  as  software  with 
hardware  assists;  the  dynamic  address  translation  of  virtual  system  being  a 
case  in  point.  To  define  something  through  its  functional  characteristics 
often  runs  the  risk  of  an  incomplete  definition  if  some  .unctions  are  left 
out.  In  the  case  of  computing  systems,  we  actually  have  the  situation  in 
reverse;  namely,  that  although  some  of  today's  smaller  systems  do  not  perform 
all  seven  of  the  above  functions,  yet  there  is  something  in  the  package 
which  we  would  unmistakenly  identify  as  an  operating  system. 

Formalism,  or  a  "theory"  of  operating  systems  is  clearly  lacking.  The 
implementation  of  a  system  had,  in  the  past,  been  more  or  less  drawn  from  the 
designer's  own  accumulated  experiences,  strictly  on  ad  hoc  basis.  To  a 
large  degree,  it  still  does  today. 
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Perhaps  we  should  look  at  the  operating  system  as  being  part  of  a  total 
system  that  consists  of  mostly  software  system  routines,  together  with  some 
hardware  complements,  performs  controlling  functions  and  carries  out  decision 
making  processes.  Hardware  components  become  part  of  the  resources  under  the 
aegis  of  the  operating  system  and  together  they  form  the  complete  computing 
utility  in  the  eyes  of  the  user. 
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CHAPTER  III 

Resource  Related  System  Abstractions 

3.1  Introduction 

In  the  previous  chapter,  we  have  discussed  and  recognized  that  although 
the  system  software  began  its  life  subservient  to  the  system  hardware,  the 
third  generation  of  computer  system  really  established  the  synergism  of  these 
two.  Intense  effort  has  been  directed  at  the  studying  of  various  aspects  of 
the  Operating  System.  The  path  through  the  labyrinth  to  the  central  chamber 
of  understanding  has  not  yet  been  found;  we  still  cannot  define  the  operating 
system  satisfactorily.  However,  abstraction  is  our  intellectual  tool  for 
coping  with  complexity.  Many  areas  of  abstraction  have  evolved.  Some  are 
concerned  with  its  complexity  [4,5].  Others  consider  the  design  techniques 
and  correctness  [6,7].  Still  others  consider  the  system  from  its  design 
objectives  [6, 7, 8, 9].  But  the  most  viable  ones  appear  to  be  in  the  areas  of 
programming,  resource  allocation,  concurrent  processes  and  protection.  We 
will  single  out  three  specific  areas  for  discussion  in  this  chapter.  They 
are:  concurrent  processes;  queueing  model;  working  set  model.  The  reason 
is  that  all  three  are  either  implicitly  or  explicitly  connected  with  system 
resources.  A  process  is  considered  to  be  the  smallest  unit  of  work  that  needs 
system  resources.  Queueing  theory  and  models  deal  with  scheduling  algorithms; 
scheduling  in  the  sense  of  controlling  the  flow  of  processes  and  not  of 
actually  allocating  any  resources.  Processes  will  "queue-up"  as  the  compu¬ 
tation  demands.  Working  Set  Model  attempts  to  view  a  specific  resource  allo¬ 
cation  problem,  i.e.  memory  management  in  a  paging  machine,  through  user  program 
properties . 

In  section  3.2,  we  discuss  the  various  states  a  process  may  encounter 
throughout  a  computation.  Because  of  the  various  resource  demands,  a  dead¬ 
lock  situation  could  happen  if  we  do  not  place  any  condition  on  granting 
requests.  In  section  3.3.,  we  begin  by  examining  a  single  queue  model  in 
fairly  detailed  manner.  Some  of  the  current  studies  in  queueing  are  then 
briefly  reviewed  and  their  difficulties  discussed.  In  section  3.4  we  examine 
the  memory  allocation  problem  through  the  concept  of  Working  Set.  This  area 
has  attracted  considerable  interest  and  intense  efforts  ever  since  its  incep¬ 
tion.  But  we  feel  that  some  of  the  questions  involved  are  still  unresolved. 
Finally,  in  section  3.5  the  whole  question  of  system  performances  will  be 
carefully  re-examined. 
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3 . 2 _ Concurr ent  P recesses 

Process  is  an  abstraction  of  the  activity  of  a  processing  unit.  The 
precise  moment  of  its  inception  is  somewhat  vague.  It  appears  that  the 
concept  was  the  outgrowth  of  several  major  system  design  projects  such  as 
MULTICS  and  OS/360.  It  is,  on  a  conceptual  level,  the  smallest  unit  of  work 
(of  the  individual  user)  that  is  contending  for  system  resources.  In  OS/360 
terminology,  it  is  called  a  task.  This  abstraction  was  needed  to  aid  in  the 
implementation  of  the  mechanism  of  preempting  and  restarting  programs  without 
affecting  their  computational  results.  No  precise  definition  of  a  process 
has  been  agreed  upon  but  the  concept  is  generally  accepted.  It  is  to  be 
distinguished  from  a  program  in  that  a  program  can  be  thought  of  as  a  collection 
of  individual  instructions  occupying  some  address  space,  usually  contiguously, 
therefore  static,  while  the  dynamic  nature  of  the  process  is  implicit.  Then 
is  seems  quite  natural  to  look  upon  an  individual  program  as  a  collection  of 
different  processes.  Processes  arise  and  dissolve  in  the  course  of  program 
execution,  acquiring  and  releasing  resources  along  the  way.  In  other  words, 
the  unit  of  decomposition  of  a  user's  program  is  the  process  rather  than  the 
usual  main  program,  subroutine(s)  division  which  is  a  mere  static  partition 
in  address  space.  The  system  is  then  a  collection  of  different  processes 
from  different  users.  This  view,  in  fact,  pervades  the  design  of  THE  multi¬ 
programming  system  [4]. 

A  large  number  of  processes  in  a  system  are  independent  from  each  other. 
Assuming  the  availability  of  resources,  each  such  process  Is  logically  capable 
to  proceed  and  in  asynchronous  manner.  The  example  that  immediately  comes  to 
mind  is  the  CPU  and  channel  overlap.  There  is  no  doubt  that  utilizing  the 
concurrency  in  processes  results  in  speed-ups.  But  due  to  its  asynchronous 
nature,  each  process  potentially  proceeds  at  a  different  speed.  The  system’s 
controlling  mechanism  then  has  the  burden  of  coordination.  The  basic  types 
of  coordination  needs  are:  1)  Synchronization ;  2)  Mutual  Exclusion.  There 
is  another  problem  area  due  to  limited  resources  among  the  competing  processes, 
i.e.  the  deadlock  problem. 

If  system  resources  are  unlimited,  there  are  only  two  states  that  a 
process  can  assume  between  its  creation  and  termination,  namely,  active  and 
blocked .  A  process  in  active  state  is  a  process  that  is  productive.  If,  for 
some  reason,  the  process  cannot  proceed  any  further,  it  is  put  in  limbo,  or, 
blocked  state.  Since  it  is  assumed  that  unlimited  amount  of  resources  are 
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available,  the  reason  for  suspension  is  not  for  lack  of  processor  or  memory, 
etc.  The  process  is  blocked  because  other  processes  are  "behind  in  progress"; 
this  is  the  characteristic  of  the  asynchronism  among  processes.  The  states 
are  depicted  in  Figure  3.2.1. 

Realistically,  no  system  has  unlimited  resources.  Therefore,  there  is 
a  ready  state  in  which  a  process  is  waiting  for  its  resource  requirements  to 
be  fulfilled.  The  situation  is  represented  in  Figure  3.2.2. 

Consider  a  set  of  processes  {p^,p  , . . .  .p^  each  of  which  is  in  some  state 

of  execution  and  let  (r. ,r„,...,r  }  be  a  set  of  resources  already  in  use  by 

1  L  m  - 

these  processes.  A  process,  p^,  which  possesses  r.  at  the  time  and  also 
wishes  to  acquire  r^  can  be  depicted  by  a  resource  state  graph  [47]  as  in 
Figure  3.2.3. 

Each  resource  is  represented  by  a  node.  The  label  on  the  node  is  the 
process  which  currently  possesses  this  particular  resource.  If  this  process 
is  requesting  additional  resource,  then  it  is  represented  by  an  arc  from  the 
current  resource  node  to  the  resource  node  being  requested.  Hence,  the 
resource  state  graph  represents  the  state  of  current  resource  possessions  and 
current  resource  requests. 

For  a  simple  2  processes  and  three  resources  system,  Figure  3.2.4  is  a 
possible  resource  state  graph.  It  shows  that  process  p^  is  active,  possessing 
r^,  and  is  requesting  r 2;  p2  is  active,  possessing  r3>  and  is  requesting  ^ 
and  r2*  The  situation  presents  no  problem;  p2  will  be  blocked,  assuming  no 
preemption  of  resource  r^  from  p^.  However,  if  there  were  a  third  process, 
p^,  already  in  control  of  r2  and  requesting  r^,  then  this  would  have  created 
a  circuit  (directed  loop)  in  the  resource  state  graph  as  in  Figure  3.2.5. 

In  this  case,  all  three  processes  will  be  blocked  and  all  three  resources 
will  not  be  available  to  the  system  pool.  If  there  is  no  more  other  process 
either  active  or  in  ready  queue,  the  entire  system  comes  to  a  standstill, 
i.e.,  deadlock.  It  has  been  shown  that  the  existence  of  a  loop  in  the  resource 
state  graph,  i.e.,  a  circular  wait  for  the  processes,  is  a  necessary  and  suf¬ 
ficient  condition  to  cause  all  the  processes  involved  to  be  blocked  indefinitely 
if  no  outside  intervention  [10,11).  Clearly,  the  minimum  number  of  active 
processes  is  two  and  the  minimum  number  of  resources  is  also  two  for  a  minimum 
loop  to  exist  in  a  resource  state  graph. 

Let  us  consider  under  what  conditions  that  would  lead  to  the  circular 
circuit  situation.  They  are  as  follows: 


IK 


IK 
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Fig.  3.2.1  Process  States  -  unlimited  resources 


Fig.  3.2.2  Process  States  -  limited  resources 


Pi 


Fig.  3.2.3  A  resource  state  graph 


1)  Mutual  exclusion  —  processes  claim  exclusive  control  of  the 
resources  they  require. 

2)  Wait  for  condition  —  processes  hold  resources  and  asking  for  more. 

3)  No  preemption  —  resources  cannot  be  forcibly  removed. 

In  fact,  in  order  to  have  a  circular  wait,  all  three  must  exist  at  the 
same  time.  Clearly,  this  presents  some  obvious  strategy  to  prevent  the  dead¬ 
lock  from  happening,  i.e.,  to  prevent  the  existence  of  one  or  more  of  the 
above  conditions.  We  must  allow  each  process  to  hold  at  least  one  of  its 
resources  exclusively,  therefore,  condition  1  cannot  be  denied.  To  allow 
preemption  on  some  resources  could  be  very  costly,  in  terms  of  the  potential 
waste  on  the  processing  already  done.  This  leaves  condition  2  which  can  be 
avoided  by  stipulating  that  each  process  must  request  all  resources  needed 
at  once  and  cannot  proceed  until  all  have  been  granted.  The  latter  approach 
had,  in  fact,  been  in  use  in  some  systems.  Another  approach  is  to  impose  a 
linear  ordering  of  resource  types  on  all  processes.  It  can  be  shown  that 
this  hierarchical  structuring  would  prevent  the  loop  from  existing  in  the 
resource  state  graph  and  this  was  the  approach  taken  in  the  design  of  OS/360 
MVT  system  [11].  The  other  ways  of  handling  this  deadlock  problem  are: 
detection  and  recovery  and  avoidance.  These  two  are  much  more  involved  and 
are  still  under  conceptual  investigation.  In  any  case,  the  deadlock  problem 
exists  as  a  logical  possibility  which  arises  from  process  concurrency  and 
the  way  processes  are  managed.  However,  deadlock  situation  in  real  life  is 
not  prevalent.  Whether  or  not  one  should  have  the  costly  prevention  mechanism, 
or  even  costlier  detection/avoidance  algorithm  built  in  is  a  matter  of  system 
design  philosophy  that  is  open  to  conjecture.  The  point  is  that  such  a  situa¬ 
tion  is  of  low  frequency  in  nature  and  its  effect  is  not  fatal  in  the  sense 
of  total  loss  in  information,  or  worse,  incorrect  computational  results.  Which 
brings  back  our  discussion  on  the  question  of  correctness. 

Since  we  envision  the  system  as  a  set  of  asynchronously  cooperating 
processes,  it  is  imperative  that  the  final  result  should  be  independent  of 
the  relative  speed  of  individual  processes.  The  contribution  by  Dijkstra  in 
this  regard  is,  of  course,  fundamental.  He  proposed  a  set  of  indivisible 
operations  P  and  V,  based  on  the  concept  of  semaphore  which  by  definition 
is  non-negative  on  initiation  [4], 

These  synchronizing  primitives  are  used  for  the  purpose  of  interprocess 
communication.  A  famous  example  was  the  so-called  Reader/Writer  problem,  used 
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to  illustrate  the  I/O  activity.  Not  only  do  these  primitives  solve  the  syn¬ 
chronizing  problem  but  they  handle  the  mutual  exclusion  problem  as  well. 

These  primitives  have  been  used  in  various  situations  and  assumed  perhaps 
different  names,  e.g.,  LOCK/UNLOCK,  WAIT/SIGNAL.  It  should  be  observed  that 
the  idea  relies  upon  certain  assumptions:  that  P  and  V  can  be  operated  with¬ 
out  division  and  interruption;  therefore,  while  in  progress,  it  must  be  guaran¬ 
teed  exclusive  access  to  any  resources  it  requires.  It  should  be  remembered 
that  this  is  a  concept  and  a  recipe;  a  concept  that  shows  what  is  minimally 
required  to  achieve  the  synchronization  (or  mutual  exclusion)  requirement 
and  a  way  to  do  it.  In  reality,  it  still  depends  on  the  actual  hardware  on 
hand  and  the  method  of  implementation.  This  is  not  so  straightforward  [12]. 
Furthermore,  it  is  up  to  the  individual  designer  to  provide  a  queueing 
discipline  to  handle  the  queue  of  the  blocked  processes.  Also,  provision 
must  be  made  to  preclude  the  possibility  of  a  process  being  blocked  indefinitely. 

Since  its  inception,  the  concept  of  semaphore  has  been  much  refined  and 
capabilities  added.  It  is  not  our  intention  to  give  a  complete  treatise  on 
the  subject  in  our  current  discussion .  A  comprehensive  treatment  can  be 
found  in  a  book  by  Brinch  Hansen  [48].  In  summing  up  this  portion  of  the 
discussion,  we  will  make  the  following  two  observations: 

1)  Perhaps  the  most  important  point  of  the  P/V  operations  is  that 

in  thinking  this  way,  a  programmer  forces  himself  to  use  a  set  of 
mental  tools  and  when  employed  carefully,  the  resultant  codes  are 
at  least  demonstrably  correct. 

2)  The  questions  of  resource  utilization,  system  efficiency,  and  the 
speed  with  which  the  processes  proceed,  hence  the  overall  system 
throughput,  do  not  come  into  the  picture. 

3.3_  Queueing  Model 
3.3.1  Preliminary 

Queueing  theory  is  one  branch  of  applied  mathematics,  i.e.,  applied 
probability,  and  is  also  known  under  other  names  such  as  traffic  theory, 
congestion  theory,  the  theory  of  mass  service,  and  the  theory  of  stochastic 
service  systems,  etc.  It  has  been  developed  in  an  attempt  to  predict  fluc¬ 
tuating  demands  from  observational  data  and  to  enable  an  enterprise  to  provide 
adequate  service  for  its  customers  with  tolerable  waiting  time.  The  first 
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analytical  treatment  of  Poisson  queues  was  applied  to  the  telephone  traffic 
engineering  by  A.  K.  Erlang  of  Copenhagen. 

In  a  service  facility,  queues  (waiting  lines)  are  formed  due  to  the 
scarcity  of  resources.  Many  familiar  situations  arise  in  many  diverse 
segments  of  real  life.  For  example:  the  relationship  between  the  in-patients, 
out-patients  and  the  number  of  sick  beds  in  a  hospital;  aircraft  landing  and 
take-off  rates  and  the  number  of  runways  in  an  airport;  arrival  and  departure 
of  ships  and  the  docking  (loading/unloading)  facilities  of  a  harbor;  traffic 
patterns  in  the  city,  toll  booths,  tunnel,  etc.;  inventory  in  business; 
repairmen  problem;  assembly  line  problem,  so  on  and  so  forLn.  Queueing  theory 
has  been  applied  success ful ly  to  various  situations  in  all  of  the  above  cate¬ 
gories  when  the  various  probability  dist ribut ions  were  carefully  observed  and 
the  model  being  carefully  constructed  and  analyzed.  It  was  successful  in  the 
sense  that  the  prediction  (expectation  value)  agreed  quite  well  with  the  actual 
value  (observat ional  data).  Many  illuminating  examples  were  given  by  Saaty  [13). 

Let  us  now  examine  the  situation  concerning  the  computer  systems.  From 
the  utility  point  of  view,  users  are  the  customers,  the  system  is  the  facility. 
Resources  (CPU,  memory  space,  1/0  channels,  etc.)  are  scarce.  Queues  are 
necessarily  formed.  Given  the  successes  of  queueing  theory  in  other  conges¬ 
tion  problems  as  a  back  drop,  it  is  quite  natural  to  try  a  similar  approach 
to  computer  systems.  In  the  ensuing  discussions,  we  will  first  present  the 
basic  hypotheses  and  results  of  a  simple  queue.  Then,  queueing  in  the  context 
of  computer  systems,  both  theoretical  and  systems  modelling  are  briefly 
described  and  then  a  re-examinat ion  on  some  problem  areas. 

3.3.2 _ A  Basic  Queue 

A  queueing  model  consists  of  servers  where  customers  receive  services 
and  of  queues  where  customers  can  wait  if  all  servers  are  busy.  The  simplest 
model  has  one  server  with  one  queue,  a  single  channel  queueing  model,  as  in 
Figure  3.3.1. 

A  queueing  model  with  above  structure  is  completely  characterized  by 
three  things:  input  process,  service  distribution  and  queueing  discipline. 

A  set  of  differential-difference  equations  governing  the  interrelationship 
among  the  members  of  the  queue  can  be  derived  from  birth-death  process  and 
the  associated  hypotheses.  See,  for  example.  Cooper  [14],  and  of  course. 

Feller  [15]. 
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SERVICE  FACILITY 


Fig.  3.3.1  Single  Channel  Queue 


A.  Birth  and  Death  Process 


Consider  that,  for  each  fixed  time  f,  0  <  t  <  00 ,  a  system  can  be 
described  by  a  random  variable  N(t)  which  assumes  a  certain  value  with  a 
probability.  There  is  no  loss  of  generality  if  we  consider  integer  values. 
We  say  that  a  system  is  in  state  E^  at  time  t  if  N(t)  -  j ,  j  *  0,  1,  2,  . . . 
Postulates : 

(1)  System  only  changes  through  transitions  from  states  to  their  next 
neighbors,  i.e. 

E.  -*■  E  or  E.-*-E.  for  j  -  1 
J  j+1  J  J-l 


and  Eq  E^  only. 

(2)  If  at  time  t  the  system  is  in  state  E^ ,  the  conditional  probability 
that  during  the  interval  (t,  t+h)  the  transition  Ej  -*■  Ej+^  occurs 
is  equal  to  Xjh+0(h),  j  *  0,  1,  2,  ...  A  is  the  birth  rate  of 
the  system  at  state  E^  and  0(h)  denotes  a  quantity  which  is  of 
smaller  order  of  magnitude  than  h.  That  is, 


lim  OOO  _ 
h->0  h 


(3)  Similarly,  the  conditional  probability  of  the  transition  E^  -*•  E^_^ 
is  equal  to  p^h  +  0(h),  j  =  1,  2,  3,  ... 

(4)  The  probability  that  more  than  one  change  occurs  during  interval 


(t ,  t+h)  is  0(h) . 

A  process  obeying  the  above  postulates  is  called  a  birth-and-death 
process . 

If  we  denote  P.(t)  to  be  the  probability  that  the  system  is  in  state  E 


at  time  t,  i.e.  ,  P (t) 


P[N(t)*jl,  then  we  can  calculate  P^(t+h)  from  the 


j 


above  postulates 
possibilities : 
(1) 

(2) 


At  time  t+h  the  system  can  be  in  state  E^  with  the  following 


At  time  t,  system  is  in  E^ ,  during  (t,  t+h)  system  stays  in  E^  . 


At  time  t,  system  is  in  ^  and  that  transition  Ej_^ 
during  (t,  t+h). 

(3)  At  time  t,  system  is  in  and  that  transition  Ej+j 

during  (t,  t+h). 

(4)  More  than  two  transitions  occur. 


Ej  occurs 


Ej  occurs 


It  follows  from  the  postulates  and  the  law  of  total  probability  that 
P^t+h)  -  [1-(X  4Vj)h]  PjCt)  +A  hP  (t)  +uj+1hPj+1(t)  +0(h) 


P,(t+h)  -P,(t) 


'<  WPJ(t>  ♦  ♦  VlP1+1co 


Note  that 


lim  0(h)  n  .  lim  Pi(t+h)  "  P1(t)  d  f  ... 
h-K)  ~h~  =  °  and  h-0 - h - dF  [Pj(t)1- 


We  have 


1£  'Vt)]  '  VlPJ-l(t)  +  VlPJ+l(t)  '  <WPj<«> 


subject  to 


X-1  “  v0  '  p-i(t)  “ 


(3.3.1) 


(3.3.2) 


Furthermore,  if  at  t  =  0  the  system  is  in  state  E^,  the  initial  conditions 


(1  if  j  =  i 
P  (0)  -J 

3  { 0  j  J*  1 


The  coefficients  {X.Jand  (y,}are  called  the  birth  and  death  rates, 
3  j 

respectively. 


B.  Input  (arrival)  process  of  a  queue  -  Pure  birth 

Pure  birth  means  {p  }  *  0,  and  we  shall  consider  the  case  of  constant 
birth  rate,  i.e. ,  X  =  X. 


Assuming  that  system  is  in  at  t  *  0,  then 
[Pj(t)J  =  AP  (t)  -  XP  (t) 


(3.3.4) 


P,(0) 


1  j  -  0  j  -  0,  1,  2,  ... 


0  j  *  0 


P_1(t)  -  0 


The  general  solution  can  be  obtained  recursively  as 


V°  -  —  e  *  2’  ••• 


(3.3.5) 
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Note  that 


I  P.(t) 
j-0  3 


1  for  t  >  0  . 


Recall  that  P^(t)  a  P [N ( t ) “ J ] ,  we  therefore  conclude  that  the  random  variable 
N(t)  has  the  Poisson  Distribution  with  mean  At.  In  other  words,  we  say  that 
the  arrival  process  for  customers  to  a  queue  facility  is  Poisson. 


Cj  Service  Time  Distribution 

Consider  a  basic  model  of  Bernoulli  Trials.  A  Trial  (experiment)  is 
performed  every  unit  time.  A  Failure  is  that  the  service  continues  and  a 
Success  means  termination.  Let  p  be  the  probability  of  success.  Then 
(1-p)  is  the  probability  of  k  trials  resulting  all  in  failures.  In  our 
context,  this  means  that  the  waiting  (or  service  time)  is  at  least  k  since 
a  trial  is  performed  every  unit  time,  i.e. 

Pr [T>k]  =  (l-p)k.  (3.3.6) 

The  expected  number  of  success  (terminations)  in  k  trials  is  (kp) .  If 
k  trials  took  place  in  interval  t,  then  the  mean  number  of  success  per  unit 
time,  p,  is 

V  -  (3.3.7) 


Suppose  k  -*  p  -*  0  in  such  a  way  that 
kp  =  ut  =  a  >  0, 


lim  (l-p)k  =  lim  (l--^)k 

p-*0  k-*° 

k-** 

=  e'Mt  (3.3.8) 

Therefore,  Bernoulli  Trials  lead  to  Geometric  Distribution  and  in  the  limit 
it  approaches  the  Negative  Exponential  Distribution.  Furthermore, 

Pr[T>t+At|T>t]  - 

-U(t+At) 


.  e-V(At) 

-  Pr [T>At ] . 
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This  means  that  the  probability  for  a  customer  to  wait  (being  served) 
additional  time,  At,  is  the  same  regardless  how  long  he  has  waited.  This 
is  the  Markovian  property  (memory less) . 


D.  A  Stationary  Queue 


For  statistically  equilibrium  case,  P'^.(t)  *  0  for  all  j.  Then, 


Eq.  (3.3.1)  becomes 


and 


yPj+1  +  XPj.-L  -  U+u)p.  =o  j  >  o 


uPj  -  »r0  -  0 


subject  to 

V. 


P_1  =  0,  pPQ  =  0 


(3.3.9) 

(3.3.10) 

(3.3.11) 


,  The  solutions  are  straightforwardly  obtained  as: 

pj  ‘  (V)J  po 

=  pJ  Pn  j  =  1,  2,  3,  ... 


(3.3.12) 


where  p  =  —  is  called  load  or  utilization  factor. 


E.  Example  of  a  Single  Server  Facility  with  Finite  Queue  Length 

Consider  a  facility  with  a  capacity  for  N  customers.  There  is  a  finite 
number  of  states,  i.e.  0  to  N.  The  finite  capacity  of  the  queue  is  (N-l) 
since  one  customer  is  being  served.  The  system  of  equations  are: 


^1  -  XPQ  -  0 

Ppj+1  +  AP^  -  (A+p)Pj  -  0  0  <  j  5  N-l 


WPN  -  XPN-1  -  0 


P  -  P  >0 
-1  N+l 

pp0  -  apn  -  0 

Clearly,  ?n  ■  pn  PQ  for  0  <  n  <  N. 
the  normalization  condition  must  hold 


(3.3.13) 

Since  P^'s  are  Probability  functions, 

,  i.e. 
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—  2  ^  i^p  -  (V)2 

(AL)  -  I  1  P 1 
i-0 


0  -  Miy1!!-,-,8  -  lo™  +  02W 
(1-p )2(l-pN+1)2 


P+  2p2 

p  <<  1 

~  N(N+2) 

P  -  1 

—  +  -4r 

P  p2 

p  »  1 

(3.3.17) 

The  mean  number  in  queue  is 
_  N 

L  -  l  (i-  1)  P. 
q  i-1  1 

=  P2  +  2P3  +  3P4  +  ...  +  (N-1)Pn 
-  p2[l  +  2p+ 3p2+  ...  +  (N-l)pN'2]  Pq 


p2[i-npn~1  +  (N-1)pN] 

(l-p)(l-pN+1) 

P  +  2p2 

|(N-1)  +  ^(N-l)(N+7)(p-l)  p  -  1 


F.  Interpretations  and  Discussion 

’(1)  For  p  «  1,  i.e.  service  rate  is  a  lot  higher  than  the  arrival  requests, 
then 

(i)  L  is  small. 

(ii)  AL  s  Sp 

&  .  £>i 

i  p 


In  other  words,  the  variance,  or  the  deviation  from  the  mean,  is  large  when 
compared  to  the  mean  itself. 

(iii)  Pq  is  the  probability  of  the  system  being  in  state  of  0,  i.e,,  no 
customer  at  all, 
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P  «  —^—2 — 
0  l-pN+1 


=  1 


therefore,  the  system  is  idle  a  large  percentage  of  the  time, 
(iv)  P^  is  the  probability  that  the  system  is  full.  If  we  agree  that 
when  system  is  full,  newly  arrived  customers  will  be  turned  away, 
therefore,  "lost". 


-  P 


« 


1 


This  is  to  say  that  when  a  system  has  a  fast  service  compared  to 
arrival  requests,  waiting  line  is  very  unlikely  to  reach  its 
capacity  therefore  very  unlikely  to  lose  any  customers. 

(2)  For  p  >>  1,  i.e.  average  service  time  is  a  lot  longer  as  compared  to 
the  average  interval  of  requests. 

(i)  L  -  N 

(11)  (AL)  -  — ^  which  is  small  if  p  »  1. 

(iii)  P_  -*•  0  and  P„  -  1 

0  N 

(iv)  All  the  above  point  to  the  conclusion  that  the  system  is  full 
most  of  the  time  and  consequently  a  large  number  of  customers 
will  be  lost. 


(3) 


For  p  -»  1,  i.e.  the  load  is  nearly  balanced. 

(i)  L  -*  N/2  if  p  =  1. 

However,  the  expected  number  of  customers  in  system  can  be  quite  sensitive 
to  the  load  factor  p,  if  N  is  large. 

(ii)  PQ  -  t~£+1] 

1-P 

_ 1 _ 

2 .  N 

1+p+p  +. , ,+p 


1 

N+l 


JlP- 


1-p 


N+l 


N 


-  _i_ 

N+l 
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In  other  words,  when  p  -*■  1,  the  fraction  of  time  when  system  is 
either  idle  or  full  is  in  inverse  proportion  to  the  system 
capacity. 

(iii)  (AL)  =  ,  if  N  »  2,  which  is  quite  large  if  N  is  large. 

(iv)  Therefore,  we  may  conclude  that  although  the  number  of  customers 
in  the  system  varies  greatly,  the  system  is  mostly  t’isy  and 
customers  are  unlikely  to  be  turned  away.. 

Summing  up,  cases  (1)  and  (2)  are  certainly  undesirable.  In  case  (3), 
we  may  have  some  room  to  work  with.  There  are  several  approaches  to  tuning 
the  system: 

(i)  For  a  fixed  N,  we  would  adjust  P,  the  load  factor,  to  be  either 

a  little  over  or  under  unity  so  that  the  expected  number,  L,  hence 
the  average  waiting  time  for  a  newly  arrived  customer  is  acceptable 
according  to  a  certain  criteria. 

(ii)  For  a  given  p,  p  -*•  1,  we  could  choose  N  such  that  and  P^  come 
within  a  certain  predetermined  value. 

However,  large  N  means  higher  cost  and  for  a  given  customer  population, 

A  is  fixed.  Hence  y  is  the  other  area  a  designer  may  be  able  to  exercise 
some  control.  In  any  case,  the  freedom  of  choice  is  quite  limited. 

3.3.3.  Queueing  in  the  Context  of  Computer  Systems 


Look  upon  as  a  whole,  the  computer  system  is  the  "server"  and  the 
individual  programs  submitted  by  users  are  the  "customers".  This  forms  a 
single  channel,  one  server  queue.  But  this  all  embracing  model  necessarily 
buries  a  lot  of  details.  If  we  look  closely,  we  would  find  processor  queue, 
memory  queue,  I/O  queue,  etc.  In  fact,  all  the  scarce  resources  form  their 
own  queues.  However,  in  each  of  these  queues,  the  interpretation  of  incoming 
"customers"  and  "arrival  processes"  are  more  subtle,  and  the  interpretation 
of  service  mechanism,  i.e.  service  time  distribution  is  very  difficult.  If 
a  system  supports  both  multiprogramming  batch  mode  and  time-sharing  inter¬ 
active  mode,  its  queue  model  would  take  on  an  extra  degree  of  complexity.  It 
should  be  noted  that  multiprogramming  need  not  be  time-sharing  and  that  a 
time-sharing  system  is  not  necessarily  multiprogrammed.  For  example,  the 
CTSS  system  of  MIT  is  a  time-sharing  system  with  at  most  one  user  in  core 
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in  any  given  time.  Nevertheless,  time-sharing  system  not  only  shared  processor 
among  users,  as  does  the  multiprogram  system,  but  also  further  characterized 
by  interactive  (conversational)  accesses.  We  may  also  look  upon  a  time¬ 
sharing  system  with  multiple  users  in  core  as  that  of  memory  sharing  as  well, 
though  not  in  the  time-multiplex  sense  as  the  processor  sharing.  In  general, 
a  majority  of  the  theoretical  treatments  on  queueing  models  are  time-sharing 
queues.  Moreover,  they  are  of  processor  queues. 

In  a  time-sharing  environment,  a  user  is  sharing  the  server  (processor) 
in  a  time-multiplex  fashion.  But  in  a  given  user-system  interaction,  the 
required  processor  services  may  exceed  one  time  allotment.  Therefore,  it 
is  natural  to  think  of  the  user  as  being  ejected  from  the  server  (processor) 
and  then  rejoin  at  the  end  of  the  queue.  Instead  of  the  f irst-come-f irst- 
served  discipline  as  the  simple  queue  discussed  in  last  section,  we  have 
now  a  modified  queue  discipline  (or  service  discipline)  for  the  time-sharing 
queue.  Generally,  they  can  be  classified  as  Round-Robin  (RR)  or  Priority 
or  Foreground-Background  (FB)  Queue.  (Fig.  3.3.2) 

Kleinrock  [16]  was  among  the  first  to  study  this  model.  Rasch  [17] 
further  studied  this  RR  model,  with  and  without  overhead.  Priorities  were 
also  assigned  to  incoming  users  based  on  decreasing  function  of  program 
length.  Heacox  and  Purdom  [18]  continued  to  investigate  the  variation  of 
RR  model.  They  called  their  model  SQ  (Single  Quantum)  and  MQ  (Multiple 
Quantum)  Model.  SQ  is  the  conventional  RR  model.  However,  MQ  is  a  modifi¬ 
cation  in  which  the  amount  of  service  per  pass  depends  on  the  rate  at  which 
programs  arrive  in  the  system. 

Many  people  have  studied  the  N-Level  Foreground-Background  (FB^)  Model 
(Fig.  3.3.3.).  Among  those  are  Coffman  and  Kleinrock  [19].  All  but  level  1 
are  background  queues.  The  distribution  of  waiting  time  is  controlled 
through  the  altering  of  the  processor  time  quantum  size  or  changing  the 
number  of  levels,  N.  Additional  control  may  be  obtained  through  the  use  of 
external  priority  assignments.  It  should  be  noted  that  both  FB^  and  RR 
models  are  all  variants  of  a  class  of  feedback  queues.  Voluminous  amounts 
of  literatures  exist  in  the  area  of  analytic  models  of  time-sharing.  A 
good  overview  in  this  aspect  can  be  found  in  [20]. 

By  and  large,  the  types  of  analytic  time-sharing  models  are  limited 
and  the  models  differ  only  in  the  choice  for  the  following  parameters: 

(1)  Number  of  input  channels  (finite  or  infinite) 

(2)  Number  of  processors 
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(3)  Arrival  processes,  e.g.  Bernoulli,  single  Poisson  stream,  multiple 
Poisson  stream 

(4)  Service  distributions,  e.g.  Geometric,  Exponential 

(5)  Handling  of  swap  time  Tg  and  overhead  time  t^,  e.g.  Tg  -  *  0, 

T  +  T„  «  T  =  Constant  or  T  -  random 
s  0 

(6)  Quantum  assumption,  e.g.  finite  processor  quantum  or  processor¬ 
sharing  (infinitesimal  processor  quantum). 

In  the  case  of  multiprogramming  systems,  queueing  studies  appear  to  be 
relatively  few;  certainly  not  comparable  to  the  time-sharing  situation. 
Mitrani  [21]  studied  a  simple  cyclic  queue  model  of  a  multiprogramming  system 
with  a  fixed  number  of  tasks.  Specifically,  the  system  consists  of  two 
servers,  namely,  a  processor  (CPU)  and  a  channel  (PPU)  in  series  and  each 
task  must  cycle  through  these  two  servers  a  number  of  times  (random)  before 
termination.  Kleinrock  [22]  also  treated  a  model  with  many  processors  in 
series.  Shedler  [23]  considered  a  cyclic  queue  with  the  processor  in  series 
with  two  levels  of  memory  system  in  which  there  is  sequential  dependency  of 
accesses  between  the  devices. 

In  actual  system  studies,  perhaps  one  of  the  most  well  known  efforts 
was  the  pioneering  work  by  Scherr  [24]  on  CTSS  (Compatible  Time-Sharing 
System)  at  MIT.  The  stated  purpose  of  his  work  was  simply  to  understand 
the  various  factors  involved  in  an  interactive,  time-sharing  environment. 
Anderson  and  Sargent  [25]  analyzed  an  APL/360  system.  Moore  [26]  modelled 
MTS  (Michigan  Time-Sharing)  system  with  a  network  of  queues.  Each  had 
various  degrees  of  success  and  we  will  discuss  some  of  them,  as  well  as  the 
areas  of  difficulties. 

3.3.4  Discussions 

By  studying  a  very  simple  and  basic  queue  model,  we  see  how  some  of 
the  basic  parameters  can  be  obtained.  But  it  is  also  quite  clear  that  in 
attempting  to  adjust  some  of  these  parameters  to  accommodate  the  situation 
better,  i.e.  less  waiting  or  congestion,  the  choice  is  rather  limited.  We 
have  also  seen  the  proliferation  of  analytic  queueing  models.  In  the  treat¬ 
ment  of  time-sharing  case,  it  is  invariably  the  processor  queue  with  a 
feedback  structure.  And  the  multiprogrammed  system  is  represented  by  CPU-I/0 
cyclic  queue.  For  mathematical  tractability ,  the  arrival  process  and  service 
time  distribution  are  mostly  Poisson  and  Exponential,  sometimes  Geometric. 
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In  Che  case  of  time-sharing,  there  were  experimental  evidences  to  support 
the  assumption  that  the  inter-arrival  distribution  is  nearly  Poisson  [25, 
27,28],  However,  the  service  time,  i.e.  processor  busy  time,  is  not  Exponen¬ 
tial.  In  fact,  it  is  not  even  Hyperexponential  [28,29],  In  a  system  with 
limited  number  of  terminals  which  is  always  the  case,  then  each  arrival, 
i.e,  a  user  request,  is  not  entirely  independent  from  all  others.  This  is 
reflected  on  the  fact  that  when  the  system  load  is  heavy,  response  time 
will  be  longer  and  then  each  user  will  have  to  wait  longer  until  the  initia¬ 
tion  of  next  request.  Consequently,  the  input  rate  becomes  a  function  of 
the  service  rate.  One  might  further  question  the  validity  of  characterizing 
the  entire  system  with  a  processor  queue  alone.  Finally,  the  stationarity , 
i.e.  statistically  equilibrium,  is  always  assumed  but  seldom  verified.  While 
it  is  reasonable  to  use  the  mean  response  time  to  a  terminal  user  as  the 
measure  of  time-sharing  system  performance,  it  is  not  clear  how  one  might 
effectively  improve  such  figures  by  controlling  the  processor  time  quanta. 

For  if  we  characterize  a  system  by  a  processor  queue,  so  many  other  factors 
are  lumped  together  in  the  guise  of  Service  Time,  often  exponentially  distrib¬ 
uted,  and  not  accurate  at  that.  For  example,  how  does  one  represent  the 
delay  in  service  completion  due  to  page  fault?  Since  the  page  replacement 
policies  are  built  into  the  controlling  routines  of  the  operating  system, 
changing  the  quantum  size  of  processor  time  would  seem  futile  in  trying  to 
affect  an  improvement  in  response  time.  In  dealing  with  multi-programmed 
batch  users,  other  variables  such  as  the  programming  language  used,  individual 
coding  styles,  other  system  resources,  etc.  would  take  on  more  significance 
in  the  question  of  overall  performance.  Finally,  when  a  system  serves  a 
mixture  of  batch  and  time-shared  users,  finding  an  analytic  model  seems  out 
of  reach.  Simulation  does  appear  to  offer  promising  results  but  it  requires 
a  careful  construction  of  model  that  closely  resembles  the  real  system. 

Scherr  [24]  obtained  simulated  results  that  agreed  well  with  observations. 

And  he  took  pain  to  point  out  that  the  result  represented  CTSS  and  CTSS-like 
system  only.  Anderson  and  Sargent  [25]  also  had  good  results  in  their 
studies.  Perhaps  it  is  worth  noting  that  the  former  case  involved  in  a  study 
of  a  constant  user  pool  and  the  system  was  dedicated  to  time-sharing.  It 
was  found  that  only  mean  think  time,  mean  processor  time  (including  swapping) 
and  the  number  of  users  interacting  with  the  system  are  of  first  order 
effect.  On  the  other  hand,  Anderson  and  Sargent  [25]  found  that  the  quantum 
size  was  a  most  important  factor  in  performance,  in  terms  of  response  time; 


33 


they  were  studying  an  APL/360  system.  Moore  [26]  studied  a  system  that  is 
not  as  homogeneous  as  the  above  two,  i.e.  a  system  of  mixed  batch  and  time¬ 
sharing.  He  did  construct  a  network  of  queues  based  on  some  of  the  system's 
most  prominent  resources.  But  in  so  doing,  that  a  job,  or  a  customer  would 
go  through  the  system  being  restricted  by  the  model.  In  reality,  the  way 
a  job  might  traverse  the  systems,  i.e.  migrating  from  resource  queue  to 
resource  queue,  depends  upon  the  knowledge  a  user  has  on  the  system  and  also 
the  operating  system's  allocation  and  scheduling  policies.  It  is  not  clear 
how  queueing  models,  even  a  network  of  them,  might  take  care  of  this  situa¬ 
tion.  Finally,  we  should  recognize  that  queueing  theory  plays  essentially 
the  role  of  analysis.  We  may  hope  to  understand  the  system  under  study  a 
bit  more  if  we  are  careful  in  model  construction,  namely,  system  tuning. 

But  it  is  not  so  promising  if  we  try  to  synthesize  a  system,  based  on  queue 
models,  so  that  a  system  would  attend  a  certain  level  of  operational  charac¬ 
teristics.  The  lack  of  controlling  means  in  a  queue  model  for  system 
designers  to  consider  alternatives  under  different  .resource  constraints 
makes  this  point  apparent. 

3.4  Working  Set  Model 

A  basic  program  property  is  that  the  dynamic  footprints  of  a  processor, 
i.e.,  the  instruction  addresses  actually  visited  by  the  processor  during 
execution,  scatter  nonuniformly  over  the  uniform  address  space  of  the 
program.  This  is  generally  known  as  locality . 

Principles  of  Locality  (assuming  paging  machine) 

(1)  During  any  interval  of  time,  a  program  distributes  its  references 
(addresses)  nonuniformly  over  its  pages 

(2)  Taken  as  a  function  of  time,  the  frequency  with  which  a  given 
page  is  referenced  tends  to  change  slowly,  i.e.  it  is  quasi¬ 
stationary. 

(3)  Correlation  between  immediate  past  and  immediate  future  reference 
patterns  tends  to  be  high,  whereas  the  correlation  between  disjoint 
reference  patterns  tends  to  zero  as  the  distance  (in  terms  of 
time)  between  them  tends  to  infinity. 

Denning  has  generalized  these  observations  into  a  user  program  model,  i.e. 
the  Working  Set  Model  [30],  Specifically,  the  working  set  W(t,T)  of  a 
process  (program)  at  time  t  is  the  collection  of  distinct  information  items 
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referenced  by  the  process  during  the  process  time  (virtual  time)  interval 
(t-T,t).  Therefore,  if  we  use  page  as  a  basic  unit  of  information  items, 

W(t ,t)  will  be  the  set  of  distinct  pages  being  referenced  T  time  units  past 
(with  respect  to  t).  T  is  called  the  working  set  parameter.  Clearly,  for 
small  T,  the  size  of  W(t,x)  will  be  small  and  larger  T  will  result  in  more 
pages  belonging  to  the  current  working  set.  Having  thus  so  defined,  the 
term  and  its  associated  concept  can  be  used  to  discuss  some  automatic  memory 
management  problems.  (Fig.  3.4.1) 

Because  of  locality,  the  processor  dwells  on  a  certain  portion  of  the 
program  more  often  than  the  others.  We  have  the  notion  that  memory  space 
is  being  effectively  used  if  the  processor  spends  most  of  its  time  in  that 
portion  of  the  space.  Similarly,  it  is  wasteful  on  the  memory  if  the  portion 
of  a  program  which  is  only  touched  by  the  processor  infrequently  also  resides 
in  the  memory  the  same  length  of  time  as  the  other  more  frequently  "used" 
addressing  space.  However,  some  parts  of  the  program  may  be  "used"  a  bit  more 
by  the  processor  than  others,  but  no  parts  of  a  program  would  be  "used" 
always,  in  a  given  time  interval.  From  the  system's  point  of  view,  it  is 
desirable  to  allocate  the  amount  of  memory  space  to  a  user  program  that  is 
just  enough  to  cover  the  range  of  processor  references  within  a  certain  time 
interval  (virtual  time)  so  that  there  will  be  more  space  for  other  users 
while  the  space  just  allocated  will  be  utilized  quite  efficiently.  For  the 
user's  point  of  view,  anything  less  than  total  program  space  in  memory  means 
that  in  a  certain  point  in  time,  the  information  item  that  is  needed  is 
missing  and  a  delay  in  the  progress  of  his  computation  will  thus  result, 
until  the  needed  information  is  found  and  loaded  into  memory.  The  less 
memory  allocated  to  a  user,  the  more  delay  it  will  be.  Clearly,  there  must 
be  a  compromise.  On  a  conceptual  level,  we  may  say  that  from  programmer's 
view  point,  the  working  set  is  the  smallest  collection  of  information  that 
must  be  present  in  main  memory  to  assure  efficient  execution  of  his  program. 
Consequently  we  may  define  that  working  set  size  is  the  largest  amount  of 
memory  that  the  system  is  willing  to  allocate  to  the  user  so  that  the  allo¬ 
cated  memory  space  will  be  utilized  efficiently.  This  remark  is  imprecise. 
Firstly,  we  don't  know  exactly  what  constitutes  an  "efficient  usage". 

Secondly,  we  don't  know  the  size  of  a  working  set  even  though  we  know  its 
definition. 

If  a  new  page  is  brought  in  on  demand,  and  if  we  do  not  allow  individual 
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user's  own  pages  to  grow  indefinitely,  at  some  point  some  pages  will  have  to 
be  displaced  back  to  the  secondary  memory.  Generally,  the  rules  by  which 
the  system  displaces  the  pages  are  known  as  replacement  algorithm.  There 
are  many  varieties  such  as  random  or  least  recently  used  (LRU).  If  we  agree 
that  a  page  may  be  displaced  after  it  falls  out  of  the  working  set,  then  the 
working  set  model  actually  constitutes  a  page  replacement  algorithm.  By 
definition  a  page  is  out  of  the  working  set  when  it  has  not  been  referenced 
in  T  time  units.  Since  a  page  is  brought  in  on  demand,  then  it  resides  in 
memory  at  least  for  T  units  of  time.  Assuming  we  know  how  to  select  t,  and 
also  assume  that  x  be  kept  constant  throughout  the  execution,  the  working  set 
size  is  still  a  function  of  t  and  it  may  grow  or  shrink  as  the  program  property 
so  dictates.  If  we  call  a  replacement  algorithm  "perfect"  in  the  sense  that 
when  a  page  is  displaced,  it  never  returns.  In  so  doing,  that  page  may  be 
kept  in  memory  unnecessarily  long  so  that  it  may  be  referenced  for  the  last 
time.  Memory  usage  is  certainly  not  high.  On  the  other  hand,  a  really  bad 
choice  in  page  replacement  would  cause  the  page  to  be  returned  "on  demand" 
after  it  had  just  been  displaced  back  to  the  secondary  memory.  A  replacement 
algorithm  based  on  the  work  set  principle  appears  to  be  a  compromise.  However, 
how  good  a  compromise  hinges  on  the  choice  of  x,  and  this  is  still  an  open 
question.  It  has  been  observed  that  a  phenomenon,  called  "thrashing",  exists 
in  a  paging  machine.  Denning  attributed  [30]  this  to  be  the  overcommitment  of 
memory:  when  too  many  working  sets  occupy  main  memory,  each  is  displacing 
another's  pages  in  an  attempt  to  have  its  own  pages  present.  This  view 
reflects  the  concept  that  the  collapse  of  the  system  (thrashing)  is  due  to 
too  many  users  in  memory.  While  it  is  true  that  for  a  given  x,  the  working 
set  size  is  a  function  of  t  and  it  can  grow,  it  cannot  displace  pages  from 
other  working  sets  if  their  pages  had  not  been  in  memory  for  at  least  X  units 
of  time,  by  definition.  If  a  particular  working  set  wants  to  grow  (as  demand 
arises)  but  found  that  all  memory  spaces  were  occupied  and  no  page  had  been 
in  residence  longer  than  x,  this  particular  set,  hence  the  program  would 
simply  be  blocked.  Instead,  we  feel  that  the  cause  of  thrashing  is  the 
result  of  improper  choice  of  x  in  the  case  of  the  working  set  scheduler  and 
a  bad  replacement  algorithm  in  general,  creating  excessive  return  traffic, 
causing  most  of  the  processes  in  page  wait  state.  In  any  case,  working  set 
is  a  concept  by  which  memory  management  policy  can  spring  forward.  Denning 
proposed  a  "balanced"  criterion  [30].  It  is  basically  an  equipment  utilization 
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criterion.  In  the  context  of  working  set,  it  is  to  load  the  individual 
working  sets  U^(t,T>  such  that 

^|wi|<8M  0<B<1 

where  M  is  the  total  memory  in  pages,  and  8  is  predetermined.  In  a  way,  this 
is  a "constrained"  approach  to  resource  (memory)  allocation. 

3.5  The  Performance  Question 

System  performance  is  one  area  of  abstractions  that  is  notably  lacking. 

It  is  something  that  is  always  implicitly  assumed  in  every  area  of  studies  in 
operating  systems  but  rarely  explicitly  defined.  Nor  can  this  situation  be 
amended  readily.  For  it  assumes  a  different  meaning  in  different  contexts. 

As  a  rule,  present  day  operating  systems  are  modularized  horizontally  with 
separate  modules  corresponding  to  distinct  features  of  the  operating  system. 
But  one  of  the  great  lessons  about  operating  system  performance  is  that  a 
system  is  not  well  represented  by  the  sum  of  its  parts.  The  response  of  an 
operating  system  to  various  loads  (resources  demands)  tends  to  be  highly 
non-linear;  the  modules  of  the  system  strongly  interact.  We  cannot  even 
specify  what  the  individual  module's  performance  level  should  be,  let  alone 
the  performance  interaction.  In  fact,  what  do  we  consider  as  performance? 

A  most  often  adopted  point  of  view  is  that  of  time.  Either  we  speak  of 
speed  (per  time  unit)  or  utilization  (percentage  of  time).  While  these 
figures  may  be  indicative  of  performance  level  in  some  pure,  absolute  sense, 
it  may  not  be  so  meaningful  in  terms  of  reality.  It  is  reasonable  to  set 
some  ranges  of  terminal  response  time  in  a  time-sharing  system  as  a  desirable 
performance  level  relative  to  the  total  terminal  users,  it  cannot  be  used 
as  a  design  specification  for  a  time-sharing  operating  system.  A  layered, 
i.e.,  vertically  modularized,  operating  system  [4]  has  the  virtue  of  clean 
interface  between  layers  and  that  the  correctness  of  each  layer  can  be 
achieved  if  the  functional  and  dynamical  properties  are  well  defined  for 
each  layer.  This  is  in  the  pursuit  of  reliability  (correctness)  at  the 
expense  of  some  execution  speed  in  the  modules.  Can  one  not  agree  that 
reliability  is  one  form  of  performance  also?  There  is  no  question  on  the 
degree  of  sophistication  of  today's  hardware.  It  is  equally  clear  that  with¬ 
out  proper  supporting  softwares,  their  potential  can  hardly  be  realized.  If 
we  view  the  entire  system  as  a  combined  package  to  provide  efficient  computing 
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utilities  to  users,  the  user  interaction  cannot  be  ruled  out  of  the  picture 
in  considering  the  question  of  performance.  For  example,  how  do  we  gauge 
the  user  satisfaction  as  a  function  of  the  total  services  that  the  system 
provides?  A  very  flexible  yet  easy  to  use  system  control  language,  a  com¬ 
prehensive  as  well  as  comprehensible  debugging  package  would  mean  more  to 
the  user  at  a  program  formulation  stage  than  sheer  speed.  In  this  sense, 
turnaround  time  or  system  throughput,  vague  as  they  already  are,  would  be 
of  even  less  consequence.  From  a  system's  point  of  view,  if  we  specify  the 
maximum  equipment  utilization  to  be  the  performance  index,  not  only  this 
will  clash  with  the  user's  own  objectives,  but  it  is  also  possible  that  a 
carelessly  implemented  policy  toward  this  end  could  lead  to  adverse  results, 
e.g.,  thrashing.  Measuring  the  processor,  I/O  channel  and  various  other 
system  resource  utilizations  are  some  of  the  "common"  approaches  in  attempting 
to  evaluate  the  system.  This  is  based  on  the  old  adage  that  performance 
automatically  means  speed  and  vice  versa.  While  this  may  be  meaningful  to 
a  certain  extent,  we  feel  that  this  view  is  too  narrow.  The  question  is 
whether  a  general  viewpoint  can  be  adopted  as  a  goal  so  that  when  achieving 
it,  we  may  say  that  the  system  is  operating  optimally.  Conceptually,  this 
goal  is  a  reflection  of  our  view  toward  the  computer  system  in  general. 

For  instance,  we  may  choose  maximum  processor  usage  or  maximum  throughput 
as  our  goal,  no  matter  how  dubious  that  may  be.  On  the  other  hand,  it  is 
equally  reasonable  to  set  a  goal  for  the  system  to  give  users  with  certain 
"qualifications"  the  maximum  advantage  of  services.  These  "qualifications" 
can  be  the  quantification  of  user  program  characteristics  or  other  arbitrarily 
set  standards.  On  the  surface,  this  would  seem  that  we  have  adopted  an 
arbitrary  measure  for  system  performances  by  setting  some  arbitrary  goals. 

But,  in  fact,  the  system  goal  viewed  this  way  is  just  a  generalization  of 
the  ordinary  priority  class  concept.  If  the  operating  system  is  designed  and 
implemented  in  such  a  way  that  it  will  always  respond  to  and  serve  programs 
with  the  highest  "qualifications"  in  the  shortest  possible  time  even  at  the 
expense  of  pre-empting  other  programs  in  execution  and  therefore  resulting 
in  a  large  amount  of  wasted  (idle)  resources,  we  would  consider  the  system 
performance  to  be  optimal  in  the  sense  that  it  accomplishes  the  predeter¬ 
mined  goal.  For  we  consider  that  if  the  system  fails  to  serve  the  program 
with  such  qualifications,  the  "loss"  could  be  much  more  detrimental  than  just 
some  wasted  resources.  An  example  of  this  "absolute  priority"  type  of  program 
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already  exists  In  the  fora  of  operator  console  routines.  Generally,  this 
"goal  programming"  approach  will  be  reflected  upon  in  the  operating  system's 
controlling  modules.  Specifically,  the  goal  is  accomplished  through  the 
system  resource  allocation  and  activity  scheduling.  We  will  come  back  to 
this  question  in  Chapter  5  with  specifics. 


CHAPTER  IV 

Operating  System  Modelled  as  a 
Conglomerate  of  Inter-dependent  Activities 


i.vk. 


4.1  Introduction 

Operating  system  has  been  viewed  as  a  set  of  cooperating  sequential 
processes,  having  defined  a  process  to  be  the  smallest  unit  of  work.  Various 
systems  of  this  kind  have  been  built  [4,6,8].  The  main  objective  of  modelling 
a  system  in  this  manner  is  to  enable  the  study  of  interacting  modules  and 
the  various  requirements  of  synchronizing  those  processes.  From  this  concept 
and  the  modelling  efforts,  one  might  be  able  to  find  some  common  principles 
with  which  the  system  functions  can  be  partitioned  into  functional  modules 
in  a  meaningful  way.  However,  this  approach  does  not  entail  the  question 
of  resource  management  in  particular  in  system  design.  We  have  discussed 
earlier  that  we  view  the  operating  system  functions  as  that  of  managerial 
nature  and  that  the  resource  allocation  question  is  paramount  if  we  view  the 
entire  computer  system  to  be  an  organization  geared  to  production,  i.e., 
computing  utility.  The  ideas  presented  in  this  chapter  are  not  unlike  those 
of  econometrics.  Certainly,  they  are  influenced  by  those  of  Dantzig  [31]. 
Section  2  gives  an  overview  on  the  activities  of  a  representative  multi¬ 
programming  system  and  the  analysis  of  the  nature  of  those  activities. 

Section  3  introduces  the  notion  of  mathematical  programming  and  basic 
postulates  on  activities,  A  specific  activity,  namely,  the  allocation 
activity  is  formally  described.  This  results  in  the  common  form  of  a  linear 
programming  problem.  Section  4  briefly  outlines  the  Simplex  Method  for 
solving  the  linear  programming  problem. 

4.2  The  Nature  of  the  System  Activities 

The  actions  that  are  taking  place  within  the  computer  system  are 
extremely  complex,  to  say  the  least.  Different  modules  of  the  operating 
system  respond  to  different  events,  both  arising  from  user  requests  and  the 
system's  own  operating  status,  in  a  generally  unpredictable  manner.  Even 
though  a  certain  action  will  take  place  in  a  certain  sequence,  most  are 
random  in  the  sense  that  the  entire  system's  operation  is  based  on  inter¬ 
rupts,  i.e.,  interrupt  driven.  In  order  to  bring  matters  into  sharper 
focus  and  to  facilitate  our  discussion,  a  simplified  overview  of  various 
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operating  system  activities  is  presented  in  Figure  4.2.1.  This  diagram 
does  not  represent  all  that  is  capable  by  a  modern  system  but  only  that  of 
a  multiprogram  environment,  supporting  local  and  remote  batch  job  queues. 
Furthermore,  the  arrows  do  not  reflect  any  hierarchical  structure  or  prece¬ 
dence  relations  among  the  system  activities.  It  is  an  indication  of  the  kind 
of  actions  that  a  job  (user  program)  may  expect  to  experience  as  it  flows 
through  the  system.  Each  circle  indicates  a  group  of  activities  for  a 
specific  purpose.  These  activities  are  carried  out  by  various  functional 
modules  within  the  operating  system.  Certainly,  they  need  their  share  of 
the  resources  in  order  to  function  properly.  They  all  need  memory  spaces 
(resident  routines)  and  some  may  need  I/O  channels,  disc  tracks,  etc.;  all 
will  need  processor  time.  Activities  thus  grouped  is  therefore  the  view 
as  seen  by  a  user  program. 

Input  Media  Conversion 

When  a  job  enters  the  system,  either  through  on-line  card  reader  or 
other  input  device  (e.g.,  communications  processor),  it  is  separated  into 
two  files.  One  file  contains  the  descriptions  of  the  job  (from  job  control 
cards)  and  the  other  is  a  data  file  which  comprises  various  subfiles  consist¬ 
ing  of  data  to  be  used  by  the  job.  And  then  the  job  is  on  the  system  job 
queue. 

Resource  Allocator 

Since  a  job  (user  program)  may  consist  of  one  or  more  stages  (job  steps), 
resource  allocation  is  given  to  each  stage  instead  of  the  entire  job.  Memory 
and  peripherals  are  assigned  to  a  specific  stage  after  the  control  tables 
(the  control  file  built  by  the  input  media  conversion  activity)  are  examined 
to  determine  gross  peripheral  requirements.  Through  this  technique  of 
allocating  peripherals  in  advance  of  execution,  the  operator  can  perform 
functions  such  as  mounting  tapes  or  specific  disc  packs  while  other  program 
or  system  activities  are  in  progress.  It  is  during  this  allocation  phase 
that  the  instructions  are  issued  to  the  operator.  When  the  assigned  periph¬ 
erals  are  ready  and  the  memory  management  module  finds  enough  space,  this 
particular  job  step  is  put  onto  the  ready  queue.  By  implication,  the  ready 
queue  consists  of  steps  of  jobs  that  are  in  memory.  However,  no  step  of 
a  job  is  initiated  unless  all  prior  steps  of  that  job  have  been  completed 
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or  otherwise  explicitly  bypassed  through  job  control  caids  under  certain 
error  conditions. 

System  Dispatcher 

The  dispatcher  is  the  center  of  control  for  job  execution.  It  only 
selects  jobs  from  the  ready  queue,  i.e.,  those  jobs  already  residing  in 
memory.  To  select  a  job  to  be  executed  is  equivalent  to  saying  that  that 
particular  job  has  been  "given  control"  of  the  processor.  A  job  that  has 
the  control  of  a  processor  is  "active".  It  can  be  delayed  due  to  either 
waiting  for  I/O  completions  or  a  forced  relinquish  by  system  timer  inter¬ 
rupt.  When  it  is  delayed,  it  is  put  back  onto  ready  queue,  figuratively 
speaking,  since  the  job  was  never  physically  removed  from  memory  and  is  now 
being  tagged  for  later  resumption.  The  ready  queue  is  dynamic  in  nature 
since  it  is  interrupt  oriented  and  since  the  dispatcher  selects  a  job  that 
would  most  readily  utilize  the  processor  rather  than  the  relative  position 
of  jobs  within  the  queue. 

Termination 

The  job,  or  the  particular  step  of  a  job,  can  terminate  either  normally 
or  abnormally,  Errors  and  accounting  records  are  produced  on  the  system 
output  file,  the  operator  is  told  if  files  require  dismounting,  tables  used 
during  execution  are  deleted,  and  memory  and  peripherals  are  deallocated. 

If  the  termination  is  only  a  job  step  and  if  there  are  more  steps  to  come, 
then  the  next  step  in  line  which  is  on  the  system  job  queue  will  be  marked 
for  allocation  consideration.  If  this  is  the  final  step,  the  system  output 
file  (for  this  job)  is  closed. 

Output  Media  Conversion 

All  output  (from  different  job  steps)  of  a  job  are  written  on  the  system 
output  file  during  execution,  and  is  only  transcribed  into  the  output  media 
(printer,  card  punch,  etc.)  after  the  completion  of  the  entire  job. 

It  is  not  explicitly  shown  but  ever  present  in  the  system  is  the  global 
event  detector  which  is  in  essence  the  interrupt  handler.  It  is  this  portion 
of  the  system  activities  that  puts  an  active  job  back  onto  ready  queue  when 
delayed  or  decides  that  there  are  more  job  steps  after  each  termination  and 
that  therefore  the  Job  flow  should  be  directed  back  to  resource  allocator,  etc. 
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Let  us  now  consider  a  specific  job.  Suppose  we  want  to  process  a 
program  written  in  FORTRAN  source  statements  together  with  data  for  execution 
if  compilation  is  successful,  a  very  common  compile-load-go  situation.  From 
our  previous  discussion,  this  job  comprises  two  stages  (or  steps).  The 
first  stage  is  compilation  and  the  second  stage  is  load-and-go.  Note  that 
in  order  to  execute,  the  object  module  must  be  loaded  first.  Hence,  load- 
and-go  cannot  really  be  considered  as  separable.  In  Figure  A. 2. 2  a  simpli¬ 
fied  job  flow  diagram  is  presented.  The  number  in  each  node  corresponds  to 
those  in  Figure  A. 2.1.  The  activities  so  described  are  fairly  typical  of  a 
multiprogrammed  batch  system.  It  should  be  pointed  out  that  the  five  activity 
phases  do  not  necessarily  reflect  the  time-sharing  environment.  Further¬ 
more,  each  program,  or  its  steps,  is  executed  in  its  entirety,  i.e.,  non¬ 
paging,  and  that  the  only  form  of  delay  comes  in  processor  preemption  and 
there  is  no  swapping  (memory  preemption)  in  the  course  of  normal  execution. 

Resource  allocation  and  scheduling  are  customarily  considered  as  a 
single  question.  But  as  we  have  made  clear  in  this  overview  that  they  are 
in  fact  two  distinct  activities  within  the  system;  scheduling  only  comes 
after  the  allocation  phase.  One  may  argue  that  in  a  broad  sense,  resource 
allocator  actually  "schedules"  jobs  from  the  system  job  queue  to  be  executed 
by  granting  their  requests  for  resources.  Viewed  this  way,  we  feel  the 
dynamic  nature  of  job  dispatching  becomes  obscured.  Furthermore,  these  two 
activities  may  actually  follow  two  quite  different  strategies  each  a  result 
of  the  design  decision  of  the  operating  system.  As  has  been  pointed  out 
earlier,  not  only  the  user  programs  demand  resources.  A  system  activity, 
or  group  of  system  activities  are  necessarily  supported  by  system  resources. 
Sometimes,  the  activity  itself  requires  file  space  (normally  disc  space 
since  most  operating  systems  are  disc  oriented)  and  I/O  channels;  this  is 
on  top  of  the  necessary  memory  space  for  the  routine  itself  and  its  share 
of  the  processor  time  to  carry  out  the  intended  action.  However,  these 
resource  requirements  do  not  compete  with  the  user  programs  in  the  sense 
that  the  resource  allocator  only  deals  with  what  is  left  to  be  granted  among 
the  competing  users.  If  we  look  at  all  the  activities  as  a  whole,  instead 
of  the  five  different  phases  as  viewed  in  the  context  of  a  job  flow,  their 
functional  natures  may  be  classified  into  the  following  three  categories: 

(1)  Housekeeping:  The  activities  that  keep  track  of  the  system  as 
well  as  the  user  program  status.  For  example,  the  creation  of 
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control  files  during  input  and  deallocation  of  resources  during 
output  and  various  interrupt  processings. 

(2)  Utility:  Mainly,  this  concerns  the  supplying  of  all  I/O  routines 
to  the  users  and  the  managing  of  all  such  I/O  processings. 

(3)  Controlling:  This  category  is  manifested  by  the  resource  allocator 
and  the  system  dispatch. 

Regardless  of  how  we  may  classify  them,  these  activities  are  all  Interdependent 
in  the  sense  that  they  either  share  or  compete  for  limited  resources  and  that 
there  are  also  precedence  relations  among  some  of  them.  All  of  them  exist 
for  the  expedient  purpose  of  keeping  a  system  operative  and  that  a  platform 
is  provided  for  an  individual  user  to  accomplish  his  computational  needs. 

In  this  light,  the  resource  allocator  and  system  dispatcher  play  a  dominant 
role  since  they  are  the  activities  directly  controlling  the  job  flow.  If 
we  think  of  the  entire  computer  system  as  a  productive  organization,  then 
the  operating  system  becomes  the  management  which  coordinates  and  supervises 
the  various  departments  towards  a  common  production  goal.  In  this  instance, 
user  programs  are  the  demands  and  the  computing  services  thus  rendered  are 
the  products.  Clearly,  in  a  limited  resource  situation,  how  best  to  dispense 
the  available  resources  to  achieve  some  predetermined  production  goal  is  the 
central  issue.  We  have  stated  previously,  in  Chapter  3,  that  the  performance 
question  of  a  computer  system  gauged  only  in  terms  of  time  is  too  narrow  a 
view.  Now  we  are  prepared  to  give  a  more  general  objective.  That  is:  a 
system  is  optimal  if  it  can  achieve  the  chosen  goal.  And  so  the  resource 
allocating  activity  should  constitute  a  policy  that  is  goal  oriented.  Even 
though  it  appears  that  the  system  production  goal  is  wholly  determined  at  the 
allocation  stage,  the  dispatcher  has  its  influence  in  an  indirect  way.  Since 
the  dispatcher  strategy  has  bearing  on  how  efficiently  the  various  resources 
are  being  utilized  after  they  are  allocated  to  individual  production  demands, 
an  efficient  dispatcher  can  have  an  indirect  effect  on  the  overall  production. 
In  the  next  section  we  shall  formalize  the  concept  of  optimal  activity  com¬ 
binations  under  constraints. 

4.3  Mathematical  Programming  and  Activity  Aggregates 

4.3.1.  The  Programming  of  Activities 

Programming,  or  program  planning,  may  be  defined  as  the  construction  of 
a  schedule  of  actions  by  means  of  which  an  organization  or  other  complex  of 
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activities  may  move  from  one  defined  state  to  another,  or  from  a  defined 
state  toward  some  specifically  defined  objective.  Such  a  plan  implies,  and 
should  explicitly  prescribe,  the  resources  and  services  utilized,  consumed, 
or  produced  in  the  accomplishment  of  the  programmed  actions.  Objectives 
must  be  stated  in  terms  of  basic  ends  thus  permitting  the  consideration  of 
alternative  means,  if  they  are  to  be  useful  in  programming  operations 
designed  to  optimize  objectives  within  resource  constraints.  Mathematical 
programming  is  concerned  with  the  problem  of  maximizing  (or  minimizing) 
functions  under  constraints.  Its  mathematical  basis  is  mainly  in  the  theory 
of  linear  inequalities  and  in  the  theory  of  convex  sets  and  functions. 

The  notion  of  programming  is  a  general  one.  On  the  user  level,  an 
individual  program  can  be  considered  as  the  organization  of  activities,  which, 
when  successfully  carried  out,  would  achieve  the  objective  of  a  computation. 
The  trend  of  using  high  level  language  removes  a  user  from  the  details  of 
resource  management.  In  fact,  he  is  oblivious  to  them.  On  the  system  level, 
the  main  concern  would  be  the  proper  coordination  of  individual  user's 
activities  under  the  limitation  of  system  resources.  It  is  the  programming 
of  the  latter  kind  that  we  will  be  dealing  with  in  the  ensuing  discussions. 

4.3.2  Basic  Assumptions 

In  the  previous  section,  we  have  come  to  perceive  the  operating  system 
as  comprised  of  various  observed  activities.  We  may  further  contemplate 
that  there  exist  some  refinements  as  representative  building  blocks  of 
different  types  that  might  be  recombined  in  varying  amounts  to  form  yet  more 
complex  but  possible  activities.  The  whole  set  of  possible  activities  will 
be  referred  to  as  a  technology,  i.e.,  the  technology  of  operating  systems. 

Postulate  I:  There  exists  a  set  (P)  of  all  possible  activities. 

Postulate  II:  There  exists  a  finite  set  of  basic  activities,  x^, 

such  that  any  possible  state  of  an  activity  can  be  represented  as 

Tax  i  -  1,  2,  ....  n  (4.3.1) 

i  1  1 

where  a^  is  the  level  of  basic  activity  x^. 

Postulate  III:  There  exists  a  linear  objective  function. 
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r  c,  x.  i  *  li  2*  • • >i  n  (4.3.2) 
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where  c^  is  a  constant  associated  with  x^,  depending  upon  a  specific 

formulation  of  the  objective  function. 

Furthermore,  we  shall  assume  that  an  activity  in  a  possible  state 
would  consume  (require)  a  certain  amount  of  resources  of  a  certain  kind, 
possibly  limited  by  a  constant  b,  that  is, 

E  a.  x  $  b  i  -  1,  2,  ....  n  (4.3.3) 

i 

4.3.3  The  Allocation  Activity 

We  will  now  discuss  a  specific  activity,  that  is,  the  second  group  of 

actions  as  depicted  in  Figure  4.2.1.,  in  the  setting  of  those  basic  notions 

put  forth  in  Section  4.3.2.  The  immediate  task  is  to  Identify  a  finite  set 

of  basic  activities.  Since  the  resource  allocator  as  outlined  in  Section  4.2 

deals  exclusively  with  user  programs,  it  appears  natural  to  choose  the  set  of 

user  programs  on  the  system  job  queue  as  the  set  of  basic  activities.  More 

precisely,  since  a  user's  program  may  consist  of  more  than  one  stage  (job 

step),  it  is  that  particular  job  step  that  is  up  for  allocation  consideration 

that  becomes  one  component  of  this  basis.  If  we  further  perceive  that  each 

possible  state  may  consume  different  kinds  of  resources,  and  that  if  we 

adjoin  these  possible  states  together,  we  have 

Ax  5  b  (4.3.4) 

where  A  is  a  rectangular  matrix,  x  and  b  will  be  column  vectors,  with  orders 

compatible  to  each  other  so  that  (4.3.4)  is  meaningful.  In  reality,  the 

number  of  elements  in  column  vector  b  is  equal  to  the  total  different  resource 

requirements  and  other  constraints  by  the  set  of  basic  activities,  the  column 

vector  x.  Thus,  the  allocation  activity  becomes  the  finding  of  a  solution 

to  (4.3.4).  Since  the  feasible  solutions  to  Eq.  (4.3.4)  are  many,  we  may 

naturally  want  to  find  the  most  desirable  one  according  to  some  criterion. 

We  have  thus  come  to  the  notion  of  goal  oriented  allocation.  That  is  if  ve 

further  establish  a  linear  objective  function  in  the  form  of  Eq.  (4.3.2)  and 

set  our  goal  to  be  the  vector  x  that  satisfies  Eq.  (4.3.4)  and  that  also 

maximizes  the  objective  function.  This  is  stated  formally  as  follows: 

Maximize:  E  c,  x.  i  *  1,  2,  ...,  n 

i  1  1  (4.3.5) 

Subject  to:  Ax  -  b 
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The  vector  x^  that  satisfies  Eq. (4.3.5) is  the  optimal  solution  and  an  allocator 
which  selects  the  individual  jobs  (or  job  steps)  corresponding  to  the  components 
of  x^  is  said  to  have  an  optimal  allocation  policy. 

4.4  The  Simplex  Method 

4.4.1  Preliminary 

Although  a  linear  programming  model  for  an  economic  problem  had  been 
developed  as  early  as  1939  by  the  Russian  mathematician  L.  Kantorovich,  his 
work  was  not  known  outside  the  Soviet  Union  until  1955.  Moreover,  it  did  not 
lead  to  a  mathematical  theory  or  to  numerical  methods.  Therefore,  it  is 
generally  agreed  that  the  year  1947  is  considered  as  the  origin  of  mathematical 
programming  when  George  B.  Dantzig  developed  the  simplex  method  for  linear 
programming  [32].  Since  then,  it  has  certainly  grown  both  in  width  and  in 
depth.  However,  it  is  not  the  intention  of  this  section  to  give  a  complete 
exposition  on  the  theory  of  simplex  method  and  linear  programming.  But  rather, 
we  will  only  present  the  method  of  solution*,  in  the  form  of  step-by-step  proce¬ 
dures.  Terminologies  will  be  explained  or  when  suitable,  given  in  the  form 
of  definitions.  Canonical  forms  of  the  Direct  Problem  (of  linear  programming) 
and  its  Dual  will  be  displayed.  An  important  Dual  Theorem  will  be  stated.  No 
proofs  will  be  given.  In  other  words,  the  materials  in  this  section  serve  as 
a  vehicle  for  later  discussions.  Detail  information  is  readily  available  from 
the  references.  In  addition  to  the  original  work  of  Dantzig  [33],  excellent 
treatments  can  be  found  in  [34,35]. 

4.4.2  Basic  Definition 

Definition  1:  Let  A  4  0  be  an  n-component  row  vector  and  b  a  scalar; 
the  set  of  all  x  for  which  Ax  5  b  is  true,  is  its  truth  set  and  is  also 
defined  to  be  a  closed  half-space  in  Rn>  the  n-dimensional  vector  space. 

Definition  2;  Let  Ax  S  b  be  a  closed  half-space,  the  bounding  hyperplane 
is  the  truth  set  of  Ax  ■  b. 

Definition  3:  A  set  C  of  vectors  in  R  is  said  to  be  convex  if,  for 
-  n  - 

every  x  and  y  in  C,  the  vector  z  ■  ox  +  (l-a)y  also  belongs  to  C,  for 
all  a,  0  -  a  5  1. 


,  K 
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number  of  closed  half-space,  i.e.,  the  truth  set  of  simultaneous  Inequal¬ 
ities  Ax  <  b. 

Definition  5:  Let  a  be  a  non-zero  n-component  column  vector  such  that 

a^  0.  Then  P(a,i),  the  1th  pivot  matrix  formed  from  a,  is  the  matrix 

obtained  by  replacing  the  ith  column  of  identity  matrix  I  by  the 

nxn 


In  solving  simultaneous  equalities,  solutions  can  be  obtained  by  repeatedly 
performing  a  pivoting  operation  on  each  column  vector.  In  dealing  with  inequal¬ 
ities,  the  first  step  is  to  turn  them  into  equalities. 

Consider  the  inequality 

Ax  <  b  (4.4.1) 

together  with  the  nonnegativity  conditions 

x  2  0,  b  >  0.  (4.4.2) 

We  define  an  m-component  column  vector  y  of  variable  y^,  the  slack  variables, 
and  consider: 


'lip ■  immw 


U 


Ax  +  y  *  b,  x  2  0  and  y  2  0  .  (4.4.3) 

Eq.  (4.4.3)  is  equivalent  to  Eq.  (4.4.1)  together  with  Eq.  (4.4.2),  since  if 
we  have  a  solution  to  Eq.  (4.4.1)  and  Eq.  (4.4.2),  then  define 


y  “  b  -  Ax  -  0  . 


Conversely,  a  solution  to  Eq.  (4.4.3)  implies  that  Ax  £  b  since  y  -  0.  A 
trivial  solution  is  simply  x  -  0  and  y  ■  b. 

In  order  to  have  a  nontrivial  solution  such  that. at  least  some  x^'s  are 
positive,  we  will  employ  the  process  known  as  restricted  pivoting. 

Consider  the  following  tableau  for  the  systems  of  equations  and  inequal¬ 
ities  of  Eq.  (4.4.3): 


yl 

y2 


(4.4.4) 


We  shall  call  the  initial  tableau  and  we  have  partitioned  T  ^  for  easy 

viewing.  To  the  right  of  are  labels  of  basic  variables.  Initially, 

they  are  the  slack  variables.  As  the  pivoting  process  progresses,  some,  maybe 
all,  y^s  will  be  replaced  by  x^'s. 

Let  T^  be  constructed  from  by  a  pivoting  process,  and  T^+*^  from 

etc.  In  constructing  a  next  tableau,  a  new  pivoting  element  and  pivotal 
row  must  be  chosen  from  the  old  tableau.  The  following  restrictions  must  be 
observed: 

Rl:  Do  not  choose  a  pivot  in  the  last  column. 

R2:  Let  J  be  the  index  of  the  column  to  be  performed  a  pivoting  process 
on,  i.e.,  "brought  into  the  basis."  For  each  i  such  that  t^j  >  0, 
compute  Now,  let  bj/tj^  ■  MinO^/tjj),  then  row  I  is  chosen 

to  be  the  pivotal  row  and  tjj  is  the  pivoting  element. 
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These  cwo  restrictions  have  the  effect  of  preserving  the  nonnegativity  of  the 
last  column  throughout  the  pivoting  process,  hence  the  conditions  x  >  0,  y  >  0 
are  met. 


4.4.4  Maximizing  a  Linear  Function  on  a  Convex  Set 

From  previous  discussions,  the  set  of  vectors  x  that  satisfies  Ax  1  b 
forms  a  convex  set.  It  is  natural  to  inquire  which  particular  vector  from 
this  set  is  the  most  desirable,  namely,  the  optimal  choice.  In  order  to 
answer  this  question,  we  must  state  our  criterion  (objective),  and  that 
introduces  an  additional  restriction  over  x.  A  simple  objective  function 
is  a  linear  function  of  x.  Ue  may  now  formally  state  the  problem  as  follows: 

Maximize :  cx 

Subject  to:  Ax  -  b  , ,  . 

(4.4.5) 

x  —  0 
b  >  0 

where  c  is  a  row  vector.  We  can  rewrite  this  problem  as  one  involving  only 
inequalities  by  replacing  the  maximizing  statement  with  the  inequality, 
cx  2  z°,  where  z°  is  a  parameter.  The  objective  now  is  transformed  into 
setting  z°  as  large  as  possible  such  that  the  inequality  system 

Ax  <  b 

cx  >  z°  (4.4.6) 

x  >  0 

has  a  solution.  If  we  replace  cx  Ji  z^  by  -cx  S  -z®,  then  the  initial  tableau 
takes  on  the  following  form: 
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Notice  that  there  are  no  slack  variables  introduced  for  the  inequality 

-cx  5  -z^.  The  reason  is  simply  that  since  z®  is  a  parameter,  we  can  adjust 

it  so  that  in  the  final  solution,  it  would  be  satisfied  as  an  equality.  And 

we  have  set  the  initial  value  of  to  be  0.  The  last  row  of  the  tableau, 

except  the  last  column,  are  called  indicators.  Initially,  x.,x„,...,x  are 

-  ^  ^  n 

non-basic  variables,  and  y. ,y,,...,y  are  basic  variables.  At  any  stage  of 

1  A  ID 

the  pivoting  process,  the  solution  to  (4.4.7)  is  obtained  by  setting  all 
basic  variables  equal  to  the  corresponding  elements  in  the  last  column,  and 
all  nonbasic  variables  are  set  to  zero.  Thus,  we  have  an  initial  solution  of 
x  *  0  and  y  ■  b,  which  is  also  a  trivial  one. 

There  are  two  additional  restrictions  we  shall  place  in  the  pivoting 
process,  namely: 

R3:  Do  not  choose  a  pivot  element  in  the  last  row. 

R4:  Carry  out  the  pivoting  on  the  column  only  if  its  indicator  is 
negative. 

The  effect  of  the  last  restriction  is  to  make  the  pivoting  process  move 

from  extreme  point  (of  the  convex  set)  to  extreme  point  in  such  a  way  that 

the  value  of  cx,  i.e.,  the  objective  function,  is  monotonically  increasing. 

For  visual  clarity,  we  have  partitioned  the  initial  tableau  (4.4.7) 

because  of  various  restrictions  placed  on  the  last  row  and  last  column.  But 

there  is  no  other  special  connotation;  we  would  still  be  referring  to  each 

individual  element  in  the  tableau  as  we  normally  would,  with  conventional 

matrix  indexing.  For  example,  t  ■  E  c  x  at  any  stage  of  the 

nrri  9  nrrn+1  ^11 

pivot  process  with  x^  the  corresponding  value  at  that  stage. 

Now  we  will  say  what  a  restricted  pivoting  process  is.  It  is  simply  the 
premultiplication  of  tableau  T^  with  a  pivot  matrix  (see  Definition  5, 
Section  4.4.2),  formed  after  selecting  a  pivotal  column  and  pivoting  element 
from  T^  in  conformance  with  restrictions  R1  through  R4. 

4.4.5  A  Recipe 

The  foregoing  discussions  can  be  fused  into  the  following  five  steps 
with  which  the  linear  programming  problem  of  (4.4.5)  can  be  solved. 

Step  1:  Select  a  negative  indicator;  call  this  column  J,  the  pivotal 
column. 

Step  2:  Calculate  b,/t.T  for  all  i  such  that  t.T  >  0. 


Choose  the  minimum  value  as  bj/t^jj  the  corresponding  rov  I 

is  the  pivotal  row,  and  t^j  is  the  pivoting  element. 

Step  3:  Form  a  new  tableau  by  carrying  out  the  pivoting  process. 

Step  4:  Replace  y  ,  corresponding  to  pivotal  row  I,  by  Xj,  corresponding 

to  pivotal  column  J.  Now,  Xj  becomes  a  basic  variable  and  the 

particular  step  is  sometimes  being  referred  to  as  "bringing  Xj 

into  the  basis",  while  y^  is  "going  out  of  the  basis". 

Step  5:  Repeat  steps  1  through  4  until  all  indicators  are  nonnegative. 

Set  all  the  nonbasic  variables  to  zero.  The  rest  of  the  answer, 

the  basic  variables,  are  the  elements  of  t.  .  . , ,  for  i  ■  1,2 , . . . ,m. 
.  l ,  m+n+i 

y 

t  ,  c-i  xj  and  is  the  maximum  over  the  truth  set  of 

m+1,  m+n+1  i  1  1 

(4.4.5). 

The  algorithm  so  described  is  known  as  the  Simplex  Method.  Note  that,  in 
Step  2,  if  there  is  no  t  >  0,  1  5  i  5  m,  it  means  that  the  maximum  problem 

1J 

has  an  unbounded  solution. 


4.4.6  Direct  Problem  and  Its  Dual 

A  linear  programming  problem  requires  the  maximization  or  minimization  of 
a  linear  function  of  variables  subject  to  linear  inequality  constraints.  In 
specific  applications,  the  original  problem  of  interest  may  be  either  a 
maximizing  or  a  minimizing  problem  from  which  the  data  matrices.  A,  b,  and  c 
may  be  derived.  If  we  formulate  one  as  Direct  (Primal)  Problem,  be  that  as 
a  maximizing  or  minimizing,  then  the  other  would  be  its  Dual.  Ue  have  been 
using  the  maximizing  problem  to  carry  the  discussion,  so  we  will  designate 
this  to  be  our  Direct  Problem,  without  loss  of  generality.  Their  respective 
canonical  forms  can  be  stated  as  the  following: 

Direct  Problem 

Maximize :  cx 

Subject  to:  Ax  5  b  (448 

x  >  0 


Dual  Problem 

Minimize :  wb 

Subject  to:  wA  2  c 
w  £  0 


(4.4.9) 
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Note  that  w  is  a  row  vector,  the  dual  to  the  original  variable  x,  a 
column  vector.  Clearly,  there  are  slack  variables  z  (a  l«n  vector  of  variables 
z^)  which  are  dual  to  slack  variables  y  (an  m*  1  vector  of  variables  y^) .  The 
equality  forms  of  both  problems  are  the  following: 


Maximize:1  cx 
Subject  to:  Ax  +  y  -  b 

x  —  0 ,  y  —  0 

Minimize:  wb 

Subject  to:  wA  -  z  *  c 

w  >  0,  z  >  0 


(4.4.10) 


(4.4.11) 


And  we  will  label  the  initial  tableau  with  all  the  variables  as  follows: 


yl  y2 


T  C0)« 


*11 

*12  *  *  * 

*ln 

1 

0 

•  •  • 

0 

bl 

a„  „ 

0 

1 

0 

b„ 

21 

22 

2 

• 

• 

« 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

*«1 

*m2 

*nm 

0 

0 

•  •  • 

1 

b® 

1 

o 

”C2 

-c 

n 

0 

0 

0 

0 

(4.4.12) 


n 

cx 


*1  *2 


*n  W1  w2 


v  wb 

D 


In  this  tableau,  we  see  that  both  cx  and  wb  point  to  the  same  entry  in 
the  tableau.  This  suggests  that  the  objective  functions  of  both  problems 
are  equal,  namely,  zero,  at  the  beginning,  and  perhaps  also  at  some  other 
points.  In  fact,  they  are  also  equal  at  the  optimum  point.  The  following 
important  theorem  states  this  fact. 

Duality  Theorem:  The  maximum  problem  has  as  a  finite  solution  a  vector 
x^  such  that  cx^  ■  Max  (cx)  if  and  only  if  the  minimum  problem  has  a  finite 
solution  a  vector  w^  such  that  w^  *  min  (wb) .  Moreover,  cx^  *  w^b. 

This  theorem  was  first  conjectured  by  John  von  Neumann  and  later  was  stated  and 
proved  by  Gale,  Kuhn,  and  Tucker  136].  We  will  utilize  the  result  of  this  theorem 
in  the  next  chapter.  Furthermore,  Simplex  Method  solves  both  problems  at  once. 
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CHAPTER  V 

Resource  Allocation  under  Linear  Constraints 

5.1  Introduction 

In  Chapter  4  we  have  singled  out,  among  all  the  system  activities,  the 
resource  allocation  activity  as  the  focus  of  our  attention.  Resources  come  in 
many  types.  In  this  chapter  we  will  examine  a  specific  type  of  resource,  namely 
main  memory.  There  are  two  basic  "commodities"  a  program  must  acquire  before 
any  computation  can  proceed.  They  are  memory  space  and  a  processing  unit.  In 
the  current  discussion,  we  will  not  consider  the  processor  requirement  as 
critical  as  the  memory  space  in  the  sense  that  a  processor  can  be  switched 
from  job  to  job  with  relative  ease,  albeit  at  the  expense  of  a  certain  amount 
of  overhead,  a  relatively  small  amount  at  that.  Memory  then  has  become  the 
most  important  and  most  scarce  of  all  resources.  In  a  simplified  viewpoint, 
we  equate  the  allocation  of  memory  space  to  a  program  to  that  of  initiating 
that  particular  program  from  system  job  queue  to  system  ready  queue.  Using 
a  common,  long-established  terminology,  we  would  say  that  this  is  "loading"  a 
program  into  the  memory.  Section  2  discusses  the  criterion  with  which  programs 
are  selected  to  be  loaded.  If  we  consider  that  the  loading  action  happens  at 
discrete  points  in  time  and  that  at  each  occurrence  of  this  action,  memory 
will  be  filled  to  the  extent  possible,  according  to  some  goal,  then  this 
action  is  static  in  nature.  That  is,  the  goal  is  either  satisfied  or  not,  at 
the  moment  of  loading,  and  not  over  a  period  of  time.  If  we  state  our  criterion 
in  the  form  of  a  linear  objective  function,  the  Simplex  Method  provides  the 
answer.  However,  practicality  prevails  in  the  consideration  of  program  loading. 
The  inherent  difficulty  in  obtaining  the  optimal  solution  is  briefly  discussed, 
and  an  heuristic  approach  is  therefore  suggested.  In  an  effort  to  present  a 
more  general  view  on  the  optimization  criterion  for  our  goal  oriented  alloca¬ 
tion  activity,  we  also  discuss  the  concept  of  value .  In  Section  3,  we  focus 
our  attention  at  the  question  of  memory  utilization  over  a  period  of  time. 

This  is  similar  to  the  question  of  space  utilization  in  a  warehouse  management 
problem,  and  the  behavior  is  dynamic  in  nature.  Various  ramifications  will 
also  be  discussed. 

5.2  Program  Loading  -  Static  Planning 
5.2.1  General  Formulation 

Although  a  program  may  require  many  different  types  of  resources  before 
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the  execution  can  be  commenced,  none  will  be  more  critical  than  memory  space. 
The  assumption  is,  of  course,  that  every  program  will  receive  its  share  of 
processor  time.  Therefore,  the  main  concern  in  resource  allocation  problem 
is  memory  space.  In  other  words,  we  choose  to  look  at  the  system  allocation 
activity  as  primarily,  at  least  for  the  moment,  as  activity  which  distributes 
primary  commodities  (memory  spaces)  among  the  basic  activities  (individual 
user  programs)  to  achieve  productions  (computations).  The  purpose  is  then 
to  devise  a  way  (a  plan)  to  allocate  those  available  memory  spaces  such  that 
the  computer  system  may  execute  programs  according  to  some  policy  (goal 
oriented) . 

Let  x^^  represent  an  individual  program  or  one  of  its  steps,  and 
(x^,X2, . . . .x^)  the  collection  of  such  programs  or  program  steps.  If  we 
follow  the  idea  as  set  forth  in  Chapter  A  and  look  upon  x^  as  a  basic  activity, 
and  if  associated  with  x^  there  is  a  number  A^,  the  "level"  of  the  activity, 
then  the  total  activity,  i.e.,  the  allocation  activity,  is  constrained  by 
the  total  resources,  M.  It  is 

A1X1  +  *2X2  +  +  \\  -  M  .  (5.2.1) 

The  interpretations  of  the  variables  are  such  that  A.^  represents  the 
individual  memory  requirement  of  program  xA  and  M  is  the  total  memory  space 
available.  We  may  consider  A^  to  be  the  size  (maximum  memory  units  required 
per  basic  activity)  of  program  x^.  Then  the  following  must  be  true: 

0  5  xt  <  1  .  (5.2.2) 


This  means  that  x^  assumes  the  value  between  0  and  1.  We  further  state  that 
the  goal  of  our  allocation  activity  is  to  plan  our  use  of  the  memory  spaces 
that  a  certain  linear  function,  namely,  the  objective  function,  is  maximized. 
This  objective  function  has  the  general  form  of 


clxl  +  C2X2  +  •••  +  cnxn  •  (5.2.3) 

Where  c^'s  are  constants.  The  canonical  form  of  this  maximization  problem  is 
the  following: 

Maximize:  cx 

Subject  to:  Ax  5  b  (5. 2. A) 

0  5  x^  -  1,  x^  Integer 


where 
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1  0 
0  1 


0 


0 


b  - 


c  -  a  constant  row  vector. 


We  can  devise  a  specific  optimal  allocation  plan  only  if  the  objective  func¬ 
tion,  i.e. ,  the  row  vector  c,  is  explicitly  defined. 


5.2.2  Illustration 


Let  us  consider  the  set  of  programs  x^,  x2  >  x3  with  memory  requirements 
40,  30,  and  20  respectively,  with  total  memory  equal  to  60  units,  i.e. 

Total  Memory 
M  =  60 


1 

Program 

Size 

xi 

40 

X2 

30 

x3 

20 

Note  that  the  program  size  and  the  total  memory  are  of  the  same  unit,  such 
as  words,  blocks,  or  pages.  Following  Eq.  (5.2.1),  we  can  write  down: 


40x^  +  30x2  +  20x^  -  60 


(5.2.5) 


In  addition  to  the  resource  constraints,  we  also  have  the  condition  stated 
in  Eq.  (5.2.2).  Combining  all  the  constraints,  we  may  write  down  a  set  of 
simultaneous  inequalities  as  follows: 


40x^  +  30x 2  +  20x^  -  60 

x  -  l 

Xi 

X  <  1 

x2 

X  <  1 

X3 

Clearly,  the  structural  matrix  A  and  the  constrain  vector  b  assume  the 
following  values: 


(5.2.6) 


- 

- 

—  - 

40 

30 

20 

60 

1 

0 

0 

t  b  - 

1 

0 

1 

0 

1 

0 

0 

1 

1 

_ 

_ 

(5.2.7) 
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What  remains  to  be  specified  is  our  objective  function. 

A.  Case  I 

If  our  objective  for  the  memory  allocation  is  to  pack  as  many  programs 
as  possible,  i.e.,  maximum  degree  of  multi-programming,  then  we  may  write 
down  the  objective  function  as: 

Maximize:  x^  +  x^  +  (5.2.8) 

The  row  vector  c  thus  becomes: 


c  =  [1,  1,  1] 


(5.2.9) 


Combining  (5.2.7)  and  (5.2.9),  adding  proper  slack  variables,  we  may  construct 
the  initial  tablues  in  the  form  of  (4.4.12)  as  follows: 


T(0)  = 


In  this  first  example,  we  will  present  the  recipe  as  stated  in  Chapter  4 
in  sufficient  details,  not  only  to  illustrate  the  Simplex  Method  but  also  by 
studying  the  step-by-step  procedures,  we  can  see  clearly  how  an  optimal  plan 
may  be  achieved.  The  algorithm  as  outlined  in  Chapter  4  treats  the  variables 
as  continuous  ones.  We  will  treat  the  variables  as  continuous  in  this  example. 
The  changes  that  must  be  made  to  the  solution  vectors  if  we  are  interested  in 
integer  values  will  also  be  discussed. 


(1)  We  have  three  negative  indicators,  namely,  t,.^,  t52»  t^.  Suppose 
we  choose  t^^.  Then  column  3  is  the  pivotal  column. 

bi 

(2)  Compute  — —  for  all  i  such  that  t  .  >  0.  They  are 

ti3  1J 


Min  (--*-) 
ci3 


1. 


Therefore,  t^  i®  the  pivotal  element  and  Row  4  is  the  pivotal  row. 


60 


(3)  Form  a  new  tableau,  T'~' ,  by  carrying  out  the  pivoting  process. 
Pivotal  element  and  pivotal  row  are  indicated  by  circle  and  arrow 
respectively. 

(4)  Since  Column  3  and  Row  4  are  pivotal,  x,  replaces  y,  to  the  right 

(1)  J  *• 

of  T  .  That  is,  x^  has  been  brought  into  the  basis  and  become 

a  basic  variable  while  y^  has  been  displaced  and  gone  out  of  the 

basis.  Therefore  it  has  become  a  non-basic  variable. 

The  above  four  steps  correspond  to  the  recipe  given  in  Chapter  4,  Section  4.4.5 
The  resulting  tableau,  after  one  pivoting  process,  becomes: 


40  30  0 

1 

0  0  -20 

10  0 

0 

10  0 

0  10 

0 

0  10 

O 

o 

© 

0 

0  0  1 

From  this  tableau,  we  see  that  a  "feasible"  solution  is  the  following: 


And  the  objective  function  at  this  stage  is: 

I  Cj  x^  ■  1  •  0  +  1  •  0  +  1  •  1 
i 

-  1 


Since  there  are  two  more  negative  indicators  left,  namely  t^  and  t,^*  we 

have  to  repeat  the  above  four  steps.  Suppose  we  choose  t^*  Then  Column  2 

is  the  pivotal  column  and  we  have  chosen  t,_  as  the  pivoting  element  and 

(2) 

Row  3,  the  pivotal  row.  Again,  we  obtain  a  new  tableau,  T  in  the  following: 


-30  -20 


6 


The  feasible  solution  at  this  point  is: 


0 

~io" 

X  ■ 

1 

.  y  ■ 

l 

1 

0 

0_ 

And  the  objective  function  has  increased  to: 

E  c  x  -1*0  +  1*1  +  1«1 
i  1  1 

-  2 


Since  there  is  one  more  negative  indicator  left, 
pivoting  process  to  be  carried  out,  according  to 
as  pivoting  element.  Row  1  as  pivotal  row.  Next 


i.e.,  t^,  there  is  one  more 

the  algorithm.  We  have  t.. 
(3) 

tableau,  T  ,  is  obtained: 


(3) 

Since  there  are  no  more  negative  indicators  left,  T  is  the 
The  feasible  solution,  which  is  also  the  optimal  solution,  is 


r<T 


final  tableau, 
now: 


9 

and  the  objective  function  E  c.  x.  -  -r  is  the  maximum  possible  under  the 

i  1  1  4 

constrains  as  stated  in  (5.2.6). 

There  are  various  ways  to  deal  with  the  Integer  Programming  problem  if 
we  desire  an  integer  solution.  If  the  number  of  variables  are  not  too  large, 
then  one  of  the  most  effective  is  the  Branch-and-Bound  method  [37],  This  method 
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is  essentially  an  implicit  enumeration  on  all  the  feasible  solutions  and 

chooses  the  solution  that  optimizes  the  objective  function.  Without  going 

into  the  details  on  Integer  Programming,  it  suffices  to  note  that,  for  this 

(2) 

particular  example,  the  pivoting  process  stops  after  reaching  tableau  T  , 
with  a  feasible,  which  is  also  optimal,  solution  of: 


and  the  objective  function  has  a  value  of  2. 

Recall  that  y^'s  are  slack  variables.  In  particular,  is  complementary 


to  the  resources  requirement,  and  y2  complimentary  to  x^. 


10;  xx  -  0,  y2 


1;  x2  ■  1,  y3  ■  0;  x3  -  1,  and  y^  ■  0. 


Here  we  have 
This  result 


indicates  that  the  maximum  degree  of  multi-programming  achieved  is  2;  programs 
to  be  loaded  are  x2  and  x3,  with  x^  idle;  10  units  of  memory  remain  unused. 

We  have  not  discussed  the  "sequence"  with  which  the  negative  indicators 
were  chosen.  What  we  have  done  is  to  have  brought  the  x^'s  into  basis  in  the 
order  of  x2»  and  x^.  Suppose  we  now  choose  the  order  x^,  x3,  and  Xj. 

The  subsequent  results  are  somewhat  different.  They  are: 
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In  their  final  forms,  the  optimal  solutions  are  identical,  regardless  of 
what  sequences  we  choose  to  bring  the  variables  into  the  basis  as  it  should 
be,  if  we  treat  this  as  a  continuous  variable  problem.  However,  it  takes  four 
steps  to  reach  the  final  solution  while  only  three  were  needed  in  the  first 
instance.  As  pointed  out  in  Chapter  4,  the  restricted  pivoting  process  solves 
the  maximization  problem  by  moving  from  one  extreme  point  to  another,  within 
the  polyhedral  convex  set,  such  that  the  linear  objective  function  is  mono- 
tonically  increasing.  A  different  sequence  in  bringing  the  variables  into  the 
basis  simply  means  that  we  move  in  a  different  route,  along  the  bounding  hyper¬ 
plane,  toward  the  optimal  solution. 

Again,  if  we  restrict  ourselves  to  integer  valued  solutions,  the  process 

(2) 

should  terminate  at  tableau  T  with  a  solution  of: 


Although  the  optimized  value  is  the  same,  namely,  the  maximum  degree  of 


«W6.  *  : 


u 


multi-programming  is  2,  but  the  choice  of  the  programs  is  different,  namely 
and  Xj.  Also,  the  two  solutions  do  differ  in  the  amount  of  memory  they 
used. 

B.  Case  II 

Suppose,  associated  with  each  individual  program,  there  is  a  “value". 
Specifically: 

Program  Size  Value 
xx  40  70 

x2  30  50 

x3  ‘  20  30 

Each  value  shown  here  is  a  quantification  of  the  relative  importance  of  each 
program.  In  this  light,  case  1  can  be  considered  as  a  special  case  in  that 
all  programs  are  of  equal  importance. 

Let  us  state  that  the  goal  is  to  find  a  subset  of  programs  to  load  into 
the  memory  such  that  the  total  values  are  at  a  maximum.  The  objective  function 
becomes : 


Maximize:  70x^  +  50x2  +  30x3 


(5.2.10) 


with  a  row  vector  c  of: 

c  -  [70,  50,  30] 

and  the  initial  tableau  is  the  following: 


(5.2.11) 


X1  *2  X3 

yl  y2  y3  y4 

b 

40  30  20 

10  0  0 

60 

H 

/— N 
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« 

10  0 

0  10 

0  10  0 

0  0  10 

1 

1 

0  0  1 

0  0  0  1 

1 

-70  -50  -30 

0  0  0  0 

0 

If  we  choose  t^  as  the  first  indicator,  then  Column  1  is  pivotal:  t21 
is  the  pivotal  element;  and  Row  2  is  the  pivotal  row.  Carrying  out  the  pivot¬ 
ing  process,  we  obtain  tableau  T^. 
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If  we  treat  this  as  a  continuous  variable  problem,  we  may  choose  Column 

(2) 

al  on/4  nK  ^  aKIonn  *T  '  • 


2  as  pivotal  and  obtain  tableau  T 
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Since  there  Is  no  negative  Indicator  left,  the  pivoting  process  terminates 
and  the  feasible  solution  Is: 


which  is  also  optimum,  with  a  total  value  of: 

E  c.  x.  «  70x,  +  50x„  +  30x_ 


70  •  1  +  50  •  (|)  +  30  •  0 


-  70  + 


However,  if  we  desire  the  Integer  solution,  then  we  should  choose  Column  3 
from  as  pivotal  column  instead,  and  obtaining  as  shown  in  the 
following: 
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cx 


Therefore,  in  the  integer  case,  we  have  as  following  the  optimal  solution: 


and  the  objective  function  has  the  value  of: 

E  c±  xt  -  70x^  +  50x2  +  30x^ 

-  70  1+50  0+30  1 

-  100 


5.2.3  Interpretations  and  Related  Questions 

We  have  tabulated  the  results  of  this  illustrative  example  under  different 
objective  functions  in  Table  5.1.  By  restricting  our  attention  integer  valued 
solutions,  we  are,  in  effect,  considering  allocation  in  a  non-paging  environ¬ 
ment.  The  solution  vector  consists  of  either  0's  or  l's,  signifying  the 
absence  or  presence  of  certain  programs  in  the  optimal  allocation  plan.  In 
Case  I,  there  are  two  possible  solutions.  Each  can  be  considered  as  optimal 
solution  since  each  achieves  degree  2,  which  is  the  maximum  possible  under 
the  constraints.  We  have  arrived  at  these  two  solutions  by  different  pivoting 
sequences.  Furthermore,  if  the  final  solution  represents  a  "plan"  to  achieve 
an  optimal  goal,  then  the  existence  of  more  than  one  final  solution  means 
that  we  have  alternate  paths  which  lead  to  the  optimum.  This  illustrates 
the  point  made  in  Chapter  4,  when  we  stated  that  in  mathematical  programming, 
objectives  must  be  stated  in  terms  of  basic  ends,  thus  permitting  the  con¬ 
sideration  of  alternative  means.  In  this  case,  our  specific  objective  is  to 
achieve  the  maximum  degree  of  multi-programming.  We  can  achieve  this  by 
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Optiaal 

Solution 

Oblectivt 

J 

Unused 

Memory  Units 

innn 

Degree  of 

Mul tiprogramming 

Value 

Case  I 

mv 

2 

2 

10 

0 

Case  II 

10  1 

100 

0 

Tabic  5.1  ftesulta  of  the  Illustrative  Exaaple 


8 


T 


either  loading  programs  and  x^,  or  alternatively,  by  loading  x^  and  x^. 

The  geometric  details  are  shown  in  Figure  5.1.  One  of  the  solution  vectors 
lies  on  the  bounding  hyperplane  of  the  memory  space  constraint  while  the 
other  does  not.  This  is  why  in  the  former  case  there  are  no  unused  memory 
units  while  in  the  latter,  there  are  10  units  of  space  left.  It  would  seem 
that  the  solution  which  utilizes  all  memory  spaces  is  a  better  choice  although 
one  cannot  make  such  a  judgement  a  priori.  On  the  other  hand,  a  very  practical 
consideration  would  favor  one  solution  over  the  other  simply  because  this 
particular  solution,  or  the  optimal  allocation  plan,  can  be  easily  devised. 

This  is  not  to  say  that  given  two  optimal  solutions,  such  as  the  ones  listed 
in  Table  5.1,  one  is  easier  to  implement  than  the  other;  the  difference  lies 
in  how  the  solutions  were  obtained.  However,  it  is  highly  impractical  for 
the  operating  system  to  set  up  and  solve  maximizing  problems  in  the  form  of 
(5.2.4)  every time  the  system  has  to  carry  out  the  allocation  activity.  The 
point  we  want  to  make  clear  is  that  to  arrive  at  an  optimum  policy,  i.e., 
finding  the  solution  which  solves  the  programming  problem  of  (5.2.4),  is  not 
necessarily  the  same  as  implementing  it.  Naturally,  it  is  very  desirable 
to  have  a  simple  allocation  algorithm  which,  when  carried  out,  would  constitute 
an  optimum  strategy;  a  strategy  that  stems  from  a  predefined  objective. 

In  light  of  this  discussion  and  if  we  look  at  the  processes  by  which  the 
two  solutions  of  Case  I  were  obtained,  we  may  state  that  the  first  solution 
can  be  obtained  by  selecting  the  smallest  program  first,  namely,  the  allocation 
unit  x^,  and  then  x^.  Since  x^  no  longer  can  fit  into  the  remaining  space, 
we  stop.  The  second  solution  can  be  arrived  at  by  selecting  the  largest 
program  first,  namely,  the  unit  x^.  Since  x^  no  longer  can  fit  into  the 
remaining  space,  we  by  pass  it  and  select  x^.  However,  one  implicit  restric¬ 
tion  on  the  loading  of  programs  is  that  we  cannot  load  and  unload  programs 
in  order  to  find  the  best  combination  such  that  a  maximum  number  of  them  can 
be  loaded;  something  that  cannot  be  explicitly  formulated  in  the  linear  pro¬ 
gramming  problem.  For  example,  if  we  change  the  size  of  x^  to  50  units 
instead  of  40,  then  the  procedure  associated  with  the  first  solution,  namely, 
smallest  first,  would  still  attain  a  multi-programming  of  degree  2,  while  the 
procedure  for  the  second  solution,  namely,  largest  program  first,  could  only 
select  x^  and  no  more;  degree  of  multi-programming  is  therefore  degraded  to  1. 
The  reason  is  simply  that  after  loading  x^,  the  remaining  space  (10  units) 
is  not  enough  to  load  either  Xj  or  x3  and  we  cannot  unload  x^  to  try  for  other 
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selections,  due  to  practical  considerations.  Hence,  we  may  state  the  following 

Proposition  5.2.1:  If  X^  is  the  size  of  program  x^,  and  if 

X,  <  X„  <  . . .  <  X .  <  X.,,  <  ...  <  X  ,  then  maximum  degree  of 

12  j  j+l  n 

multiprogramming  can  be  achieved  for  a  given  memory  size  by 
loading  first  x^  then  Xj  in  ascending  order  until  the  remaining 
space  cannot  fit  the  next  larger  program. 

Proposition  5.2.2:  If  first  j  programs  are  loaded  into  the 
memory,  and  if  (j+l)th  program  cannot  fit  in,  then  the  unused 
memory  space  is  at  most  (X^+1  -  1)  units. 

One  can  see  from  Proposition  5.2.2  that  if  one  follows  the  algirlthm 
outlined  in  Proposition  5.2.1,  the  unused  memory  space  is  potentially  large. 

To  reduce  this  potentially  large  amount  of  unused  space,  it  is  intuitively 
clear  that  one  should  deal  with  a  large  pool  of  small  programs.  Indirectly, 
this  supports  the  argument  of  a  paged  machine,  although  the  decision  for  a 
paged  machine  is  a  result  of  many  other  considerations  [8]. 

In  Case  II,  we  have  attached  a  "value"  to  each' of  the  individual  programs, 
without  elaborating  on  how  each  value  was  arrived  at.  We  will  give  a  formal 
discussion  in  Section  5.2.5.  The  Simplex  Method  would  give  a  satisfactory 
solution  if  treated  as  a  continuous  variable  case.  But,  a  straightforward 
procedure  by  which  an  optimal  solution  can  always  be  achieved,  i.e.,  a  feasible 
solution  that  maximizes  the  total  value,  is  what  actually  is  desired.  In 
this  case,  it  is  more  involved.  To  illustrate  the  problem  area,  let  us  try 
the  following  approach:  load  the  program  with  the  largest  "value"  first, 
which,  in  this  case,  is  x  ,  and  then  try  x,.  Since  x  cannot  fit  into  the 
remaining  space  which  is  only  20  units,  we  end  up  loading  x^,  thus  obtaining 
an  optimal  solution  as  listed  in  Table  5.1.  However,  if  we  change  the  size 
of  x^  to  50  units  without  changing  the  associated  value,  namely  70,  the 
procedure  just  described  would  fail  to  maximize  the  total  value  of  the  programs 
loaded  for  a  given  memory  space.  The  relation  between  the  program  size  and 
its  associated  value  must  be  taken  into  consideration. 

Suppose  we  follow  the  largest-ratio-first  rule,  then  from  Table  5.2,  we 
see  that  X2  will  be  the  first  candidate  considered  for  loading,  and  then  x^. 

If  we  only  consider  integer  solutions,  loading  x^  and  x^  with  a  total  value 
of  80  would  be  the  best  possible  choice.  Furthermore,  if  we  allow  a  fraction 
of  a  program  to  be  loaded,  i.e.,  x^'s  are  treated  as  continuous  variables, 
then  the  largest-ratio-first  rule  will  always  give  the  maximum  total  value. 
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This  is  clear  from  the  Simplex  Method;  loading  a  program  means,  in  the  con¬ 
text  of  restricted  pivoting  process,  selecting  that  particular  indicator  to 
be  "brought  into  the  basis",  as  discussed  in  Chapter  4.  However,  this  is, 
in  general,  not  true  for  integer  solutions.  Consider  Table  5.3. 

According  to  largest-ratio-first  rules,  we  would  load  x^  as  first  choice. 
If  the  total  memory  space  is  only  60  units,  there  are  only  19  units  left,  and 
not  enough  to  load  either  or  *3*  Since  reality  dictates  that  one  does 
not  unload  x^  after  loading  it  into  the  memory,  we  are  stuck  with  the  result 
of  loading  only  one  program  with  an  objective  function  valued  at  79,  while, 
in  fact,  we  could  do  better  by  loading  and  x^  instead,  with  a  total  of  80. 

Branch-and-Bound  method  can,  of  course,  handle  this  situation.  However, 
this  method  essentially  involves  implicit  enumeration  and  when  the  number  of 
candidates  on  the  system  job  queue  (see  Figure  4.2.1)  is  large,  it  becomes 
cumbersome.  It  touches  upon  the  question  of  how  one  might  classify  the 
degree  of  difficulties  of  a  given  problem.  This  will  be  taken  up  in  the 
next  section. 

5.2.4  Inherent  Difficulties  and  Heuristic  Approach 

From  our  discussion  in  previous  sections,  we  see  that  solving  the 
linear  programming  problem  has  been  reduced  by  practical  considerations, 
to  a  sequencing  problem.  That  is,  by  what  sequence  should  one  choose  the 
negative  indicators  to  be  brought  into  the  basis  so  that  when  the  process 
terminates,  the  objective  function  is  at  a  maximum?  The  analogy  is  clear 
if  we  think  of  the  "sequence  of  negative  indicators"  as  the  "sequence  of 
programs"  to  be  loaded  into  the  memory. 

We  are  dealing  with  finite  number  of  programs.  Therefore,  the  number 
of  choices  for  program  loading  sequence  is  finite.  Obviously,  there  is  a 
finite  algorithm  for  finding  a  sequence  that  is  optimal  in  some  sense;  one 
can  always  perform  an  exhaustive  search  over  the  finite  elements  in  question. 
But  the  degree  of  difficulty,  or  cost,  in  applying  an  algorithm  makes  it 
significant  the  question  of  the  existence  of  a  better-than-f inite  algorithm. 
The  relative  cost,  in  time  or  whatever,  is  a  fairly  clear  notion.  The 
problem-domain  of  applicability  for  an  algorithm  often  suggests  for  itself 
possible  measure  of  size  for  the  individual  problems.  Once  a  measure  of 
problem  size  is  chosen,  one  can  define  the  order  of  difficulty  of  algorithm 
as  the  least  upper  bound  on  the  cost  of  applying  such  an  algorithm  [49]. 

If  the  relative  cost,  in  time  or  number  of  steps,  of  applying  algorithm 
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A  to  a  problem  of  size  N  is  bounded  by 
aNb 

where  a,  b  are  constants,  then  we  say  that  the  problem  is  polynomial  bound. 
Otherwise,  it  is  polynomial  complete .  In  other  words,  a  polynomial  bound 
problem  has  an  algorithm  that  is  terminated  in  polynomial  bounded  time  (or 
steps).  Such  an  algorithm  is  called  fast  or  simple. 

There  exists  a  large  class  of  combinatorial  problems  belonging  to  the 
class  of  polynomial  complete  problems.  Knapsack  packing  is  one  of  them.  It 
has  also  been  conjectured  that  no  polynomial  complete  problem  has  a  fast 
algorithm.  We  have  used  "fast"  in  the  same  sense  as  "simple",  and  it  means 
that  the  algorithm  terminates  in  a  polynomial  bounded  time.  Clearly,  the 
memory  allocation  problem  (or  program  loading  problem,  as  we  have  phrased 
it)  is  similar  to  the  Knapsack  problem  if  we  view  each  individual  program 
as  an  indivisible  object,  with  program  "size"  being  the  "weight",  and  the 
total  memory  space  being  the  weight  capacity  that  a  person  is  able  to  carry. 
A  given  memory  space  cannot  accommodate  all  the  programs  competing  for  it , 
just  as  a  person  cannot  carry  all  the  accumulated  weight  in  the  knapsack. 

The  analogy  is  complete  when  a  value  is  attached  to  each  program,  just  as 
the  case  of  knapsack  packing  when  each  object  is  being  given  a  value,  a 
value  that  is  meaningful  to  the  person  who  carried  the  knapsack.  Knowing 
that  the  knapsack  problem  is  a  polynomial  complete  problem  should  convince 
us  that  a  simple  algorithm  to  find  the  loading  sequence  of  programs  that 
would  maximize  a  given  objective  function,  does  not  exist.  Under  the  circum¬ 
stances,  we  should  appeal  to  our  intuition  based  on  our  understanding  of  the 
complexity  of  the  problem.  Namely,  we  resort  to  heuristics. 

Let  us  assume  that  we  have  a  pool  of  programs  (x^  . . .  xr)  which  are  to 
be  considered  for  memory  space  allocation.  Associated  with  each  x^,  there 
is  a  value  of  c^,  and  the  value-to-size  ratio  can  be  formed.  Let  us  further 
suppose  that  this  community  of  programs  are  put  into  a  sorted  list  according 
to  the  magnitude  of  each  value-to-size  ratio  in  descending  order.  This 
sorted  list  has  n  items  with  the  top  and  the  bottom  each  corresponding  to 
the  largest  and  the  smallest  ratio,  respectively.  The  relative  positions 
of,  or  the  index  to,  this  sorted  list  signifies  the  magnitude  of  each  value- 
to-size  ratio  relative  to  each  other.  For  n  -  2,  the  sequencing  problem  is 
obvious.  For  n  -  3,  the  algorithm  is  shown  in  the  form  of  a  flow  chart  in 
Figure  S.2. 
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tl,c  algorithm  for  finding 


i)  at  least  one  program  can  fit  In. 
n 

11)  E  X.  x  2  M,  i.e.,  total  memory  requirement  of  all  the 
1-1  1 

programs  waiting  for  allocation  is  at  least  the  amount 
of  total  available  memory  space. 

ill)  We  are  working  with  a  sorted  list,  i.e.: 


<r>,  >(A  lfl>J 


where  i,  j  are  indices  (positions)  on  this  list. 

iv)  In  the  flow  chart,  "load  j"  means  to  load  the  program  that 
is  in  the  jth  position  on  the  list. 

Let  us  consider  yet  another  example  as  shown  in  Table  5.4.  We  reorganize 
Table  5.4  into  a  sorted  list  in  descending  order  of  the  v/s  ratio,  as  shown  in 
Table  5.5.  Assuming  that  these  six  programs  are  on  the  system  job  queue 
waiting  to  be  assigned  memory  space,  and  if  the  available  memory  space 
M»65  units,  then  our  goal  is  to  load  these  programs  that  would  fit  into  the 
memory  with  as  large  a  sum  of  total  value  as  possible.  Note  that: 
i)  M  >  i«  1,  2,  3,  4,  5,  6 

i.e.,  at  least  one  program  can  fit  in. 

6 

ii)  E  X  x  -  30  +  27  +  25  +  20  +  18  +  15 

i«l  1  1 

-  135 

>  M  ;  65 


“«  <xT>i  ’  A  1£  1  >  J 

k  p  J 

i.e.,  for  i-2  c^  *  c^  ■  61  X^  1 


X.  -  27 
4 


A  ■  ft  - 2-26 

4 


j  ■  4  c  ■  c,  ■  40  X  ■*  X.  *  20 

pi  pl 

<^>4  -  if  "  2-00 
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IC  can  be  verified  that  if  we  apply  the  algorithm  as  in  the  flow  chart 
in  Figure  5.2,  we  would  end  up  loading  program  indices  1,  4,  6  which  correspond 
to  programs  x^,  x^,  and  x^.  In  this  case,  this  choice  also  happens  to  be  opti¬ 
mal,  i.e.,  that  total  value  (70  +  AO  +  25)  “  135  is  the  largest  possible  under 
the  memory  constraint.  However,  consider  Table  5.6. 

It  can  be  shown  that  the  algorithm  in  Figure  5.2  would  select  and  x^ 
to  be  loaded  with  a  total  value  of  80,  while  the  optimum  choice  would  have 
been  x^  with  a  value  of  81.  Clearly,  the  algorithm  as  proposed  is  a  sub- 
optimal  one.  We  have  pointed  out  earlier  that  the  complexity  of  problems 
of  this  nature  is  polynomial  complete.  In  the  pursuit  of  a  simple  program 
loading  algorithm,  i.e.,  the  algorithm  itself  terminates  in  polynomial 
bounded  time,  we  have  sacrificed  the  possibility  of  obtaining  the  optimal 
feasible  solution  to  our  linear  programming  problems  at  all  times. 


5.2.5  The  Value  Concept 

In  our  previous  discussions,  we  have  used  the • term  "value"  freely, 
without  actually  elaborating  on  it.  Also,  we  have  seen  that  under  similar 
circumstances,  the  formulation  of  different  objective  functions  could  lead 
to  different  allocation  plans.  In  Chapter  3,  we  have  sought  to  broaden  our 
view  on  the  question  of  performance.  In  Chapter  4,  we  have  further  propounded 
the  notion  of  goal  oriented  allocation.  What  is  this  goal?  It  is  clear  from 
the  context  that  we  have  chosen  our  goal  to  be  the  maximization  of  a  given 
set  of  possible  values.  The  programs  thus  selected  (allocated)  would  be  of 
the  utmost  valuation  to  the  system  if  actually  processed.  Therefore,  the 
whole  question  of  system  performance  is  tied  to  the  resource  allocation 
problem  through  the  determiniation  of  a  general  objective  function.  Further¬ 
more,  this  general  objective  function  can  be  formulated  by  defining  a  general¬ 
ized  value  for  each  individual  allocation  unit,  such  as  a  job,  or  job  step. 

Definition:  For  each  program  unit  x^  there  is  an  associated 
generalized  value  cj,  such  that  c^  ■  G^^.aj^,.  ’ *  ,aki^  ^or 
i  «  1,2, . . .  ,n  ,  where  a^,  j-l,2,...,k  are  the  individual  attri¬ 
butes  of  program  i  and  G  is  any  well  defined  function  or  a 
composite  of  functions. 

As  is  defined,  the  function  G  is  perfectly  general  and  depends  on 
program  attributes  which  may  be  tangible  or  intangible.  As  an  example,  we 
may  choose  G  to  be  a  linear  functional.  Specifically,  we  will  consider: 


G"  6lFl(ali)  +  62F2(a2i)  +  •••  ■*■  6kFk(aki> 


and  6^  being  either  1  or  0 

for  i  »  1,  2,  3,  ...,n  .  (5.2.12) 


For  the  simplest  case,  suppose  we  consider  the  value  to  be  a  function  of 
only  one  parameter.  That  is: 


6l  “  1  6j  "  0  for  3- 2 . k 

then 

c,  •  F^a^)  for  i  *  1,  2,  ...,  n  (5.2.13) 


If  a^  *  A^,  i.e.,  the  size  of  the  program  and  if  we  choose  to  define 
the  function  F^a^)  as 


F 


1 


(5.2.14) 


where  a  is  a  constant,  then  the  generalized  value  c^,  so  defined  is  inversely 
proportional  to  the  size  of  program  x^  When  we  set  up  our  linear  objective 
function  as 

Maximize:  c,  x,  +  c„  x.  +  . . .  +  c  x 

we  are,  in  effect,  getting  a  maximum  degree  of  multi-programming  as  a  result. 
This  is  easy  to  see  when  we  realize  that  the  value-to-size  ratio  in  this 
case  is  inversely  proportional  to  program  size,  and  a  descending  order  of 
value/size  ratio  means  an  ascending  order  of  the  program  size.  When  using 
largest  ratio  first  algorithm,  if  this  is  treated  as  continuous  variable 
case,  or  using  the  sub-optimal  algorithm  in  Figure  5.2  as  in  integer  case, 
the  programs  will  be  loaded  in  a  sequence  with  the  smallest  being  the  first. 
From  Proposition  5.2.1  we  know  this  will  maximize  the  number  of  programs  in 
memory . 

If  we  conclude  the  possibility  that  each  job  has  been  assigned  a  priority 
class ,  it  is  quite  natural  to  incorporate  the  priority  scheme  into  our  frame¬ 
work  of  the  generalized  value  concept.  Consider  that  a^  being  the  size  of 
program  and  83  being  defined  by  (5.2.14).  We  may  consider  that 

is  the  index  to  a  certain  priority  class  to  which  program  x^  belongs.  Further¬ 
more,  let  us  define: 

F2(a2i)  *  Bit  i  -  1,  2,  ...»  n  (5.2.15) 
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(5.2.16) 


•at. » *  J". 


where  8^  Is  a  constant.  Then  the  generalized  value  Is: 


where 


Ci  "  Fl^ali3  +  F2(a2i)  i  "  1.  2,  ., 


■  £ 


F2<*21>  ‘  *i 


6i  "  62  -  1*  6j  "  0  3  "  3’  4*  5* 


• »  k 


(5.2.17) 


With  no  loss  of  generality,  we  will  consider  a. 


8.  to  be  integers  and  that : 

,  n  .  (5.2.18) 


Let  us  consider  Table  5.7.  From  our  previous  discussion,  it  should  be  clear 
that  a^  “  20,  a21  '*  D,  etc.  If  we  adopt  (5.2.18)  as  a  definition  for  F, 
then  we  have,  for  a  -  300(Table  5.8).  The  function  ?2^a2i^  will  he  defined  by 
a  set  of  integers  found  in  Table  5.9.  It  can  be  readily  verified  that  com¬ 
bining  Table  5.8  and  5.9,  i.e.,  c^  ■  Fl^ali?  +  F2^a2i3,  would  8ive  rise  t0 
each  corresponding  value  as  shown  in  Table  5.4. 

.We  can  see  that  the  priority  class  is  a  way  tl>  designate  a  certain 
"urgency",  based  on  whatever  predetermined  guidelines  that  the  system  employs, 
to  each  individual  program.  This,  by  itself,  is  artificial  and  the  artifi¬ 
cially  chosen  number,  8^,  is  a  reflection  of  this  perception.  The  choise  of 
a  is  also  somewhat  arbitrary,  so  that  the  absolute  values  of  both  F^(a^) 
and  F2^a2i3  are  conlPat*ble,  e.g.  of  the  same  order  of  magnitude.  But  this 
is  only  one  of  the  possibilities.  We  can  just  as  easily  assign  the  8^’s 
to  be  at  least  one  order  of  magnitude  larger  than  those  of  F^(a^)'s. 

In  so  doing,  the  allocation  policy  becomes  strictly  priority  oriented. 

A  more  balanced  approach  can  be  implemented  readily  by  simply  adjusting 
the  relative  magnitudes  between  functions  F^  and  F^.  In  general,  we  may 
remark  that  the  generalized  value  of  an  individual  program  is  the  composite 
of  a  set  of  functions  whose  parameters  may  be  chosen  from  intrinsic  program 
properties,  such  as  its  size,  or  subjective  reasons,  such  as  priority  classes, 
or  both. 
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5.3  Memory  Utilization  -  Dynamic  Planning 
5.3.1  General  Discussion 

In  the  previous  section  we  have  examined  the  problem  of  program  loading. 
We  have,  in  fact,  treated  such  action  in  a  static  manner.  It  is  static  in 
the  sense  that  our  goal  is  achieved  by  following  an  optimizing  plan  for  that 
particular  instance,  namely,  the  instance  of  the  operating  system's  allocat¬ 
ing  activity.  We  have  grouped  all  such  activities  into  "concentrated"  points 
in  time.  But  in  a  multiprogramming  environment,  not  all  programs  terminate 
at  the  same  time.  Each  time  a  program  (or  a  particular  step  of  a  program) 
is  done,  the  system  either  removes  this  program  or  continues  onto  its  next 
job  step.  If  a  program  is  being  removed,  then  memory  space  it  once  occupied 
would  be  available,  thus  making  it  possible  for  other  programs  waiting  on 
the  system  job  queue  to  be  loaded,  i.e.,  to  be  allocated  memory  space. 
Consequently,  the  activities  of  loading  and  removing  jobs  are  interspersed 
throughout  the  system  up  time.  Even  if  we  may  be  assumed  to  have  loaded 
all  the  programs  into  memory  to  the  extent  possible,  the  termination,  and 
hence  the  removal,  sequences  for  programs  cannot  be  predicted,  due  to  the 
fact  that  the  system  ready  queue  is  managed  in  a  dynamic  fashion,  as  was 
discussed  in  Chapter  4.  This  dynamic  management  of  the  system  ready  queue 
constitutes  what  is  considered  to  be  the  scheduling  activity.  In  this 
context,  scheduling  should  not  be  confused  with  allocation;  one  does  not 
necessarily  imply  the  other  and  vice  versa.  Furthermore,  we  have  equated 
scheduling  to  execution  sequences  for  programs.  If  we  again  consider  the 
idealized  situation  in  that  all  the  program  loading  activities  are  "con¬ 
centrated"  and  that  no  program  will  be  removed  individually  until  most 
(maybe  all)  are  completed  (terminated),  then  the  two  major  operating  system 
activities  are,  in  effect,  taking  place  cyclically.  If  each  of  such  complete 
cycles  is  called  a  period,  then  we  may  ask  what  sort  of  planning  action  can 
we  make,  i.e.,  loading  and  executing,  so  that  an  objective  function  is 
optimized  over  several  periods?  Before  supplying  answers  to  this  question, 
we  must  first  decide  upon  the  objectives.  Of  course,  the  memory  spaces  as 
necessary  and  scarce  resources  are  central  to  this  question.  Now,  it  can 
be  restated:  how  can  we  best  utilize  a  given  amount  of  memory  space  in  a 
given  processing  environment?  The  loading  (allocating)  and  scheduling 
(executing)  activities  thus  become  the  means  to  an  end.  This  brings  up 
a  well  known  model  in  mathematical  programming  applications,  namely,  the 
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Warehousing  Model  [38].  Essentially,  the  warehouse  model  is  dealing  with 
the  question  of,  given  a  fixed  capacity  and  the  buying  and  selling  prices 
of  commodities  over  several  periods  of  time,  what  action  should  the  ware¬ 
house  owner  take  so  that  his  profit  is  maximized.  In  the  ensuing  discussions, 
we  will  examine  this  question  in  the  context  of  operating  systems. 


5.3.2  Formulation  for  the  Identical  Programs  Case 

Let  us  consider  a  multiprogramming  system  where  all  the  users  (programs) 
are  identical  in  size.  This  is  neither  an  over  simplification  nor  too  far 
fetched  a  situation.  Many  so  called  express  job  queues  are  prime  examples 
of  this  category,  in  which  every  user  program  is  (normally)  given  a  fixed, 
equal  amount  of  memory  space.  The  user  programs  are  identical  to  one  another 
in  size  only,  not  the  amount  of  computations. 

We  will  denote  a  list  o£  variables  as  the  following: 

Let  x^  be  the  total  memory  space  occupied  during  period  i, 
y^  be  the  total  removed  memory  space  during  period  i, 

M  be  the  total  memory  space, 

1  be  the  initial  occupied  memory  in  period  1, 
d^  be  the  cost  per  unit  memory  during  period  i, 
g^  be  the  gain  per  unit  memory  during  period  i. 

While  some  of  the  variables  are  self-explanatory,  others  will  need  further 
clarifications.  The  variable  x^  is  in  fact  the  sum  total  of  all  the  memory 
requirements  for  programs  that  are  loaded  in  period  i  and  y^^  represents  the 
total  amount  of  memory  space  being  freed  up,  due  to  the  termination  of 
programs  during  period  i.  The  other  two  variables,  d^  and  g^,  are  arti¬ 
ficial  quantities.  We  may  think  of  the  memory  space  as  being  the  necessary 
resource  for  certain  productive  activities  and  that  it  incurs  a  cost  when 
being  occupied;  and  the  system  accrues  profit  (gain)  when  programs  are 
being  run  to  completion  and  subsequently  removed  from  memory. 

We  will  further  state  the  following  constraints: 

(1)  cannot  occupy  more  memory  (program  loading)  than  what  is  available 
in  any  period. 

(2)  cannot  remove  (program  processing)  more  memory  spaces  in  period  1 
than  what  was  occupied  in  (i  -  l)th  period. 

(3)  nonnegativity,  i.e.,  x^  yt  d  0. 


We  have  pointed  out  earlier  that  we  view  this  as  two  major  activities 
taking  place  In  a  cyclic  manner.  To  "start"  our  problem,  we  must  designate 
one  of  the  two  activities  as  the  starting  point  in  the  model.  Let  us  there¬ 
fore  assume  that,  initially,  memory  is  loaded  with  programs,  up  to  I  units. 
Thus,  we  have  arbitrarily  fixed  the  processing  activity  to  be  the  beginning 
activity  in  period  1;  loading  activity  would  follow,  thus  completing  period  1, 
etc.  The  detailed  derivation  of  the  relations  among  the  variables  is  as 
follows : 

For  i  -  1,  i.e.,  period  1,  we  have  initially  I  units  being  occupied, 
and  we  cannot  process  more  than  this  amount.  Hence 

yi  " 

If  y^  is  actually  the  amount  of  space  freed,  due  to  the  completion 
of  processing,  then  the  total  space  available  at  this  time  becomes 
H  -  (I  -  y .) 

and  that  the  loading  constraint  states  that  the  amount  of  program 
space  being  loaded  cannot  exceed  this  quantity.  Therefore, 
x±  <  M  -  1  +  y1# 

For  i  «  2,  we  have 

y2  ~  (I  '  yi^  +  *1  °r  yl  +  y2  “  1  +  X1 
and  x^  5  (M  -  I)  +  y^  -  x^  +  y2 

or  xi  +  x2  “  (M  ~  I)  +  yi  +  y2‘ 

For  i  »  3,  similarly,  we  have  ” 

yl  +  y2  +  y3  "  1  +  X1  +  X2 
and  xi  +  x2  +  x3  “  (M  -  I)  +  y^  +  y^  +  yy 

In  general,  for  i  «  n,  we  have  the  loading  constraint  as 

n 

z  (X,  -y.)  5  (M-I)  ,  (5.3.1) 

i-1  1 

and  the  processing  constraint  as 
n-1 

y  -  I  +  l  (x.  -  y.)  .  (5.3.2) 

n  i  i 


85 


From  the  definitions  of  and  we  see  that  the  net  gain  for  each  period  i 
would  be 

<8iyi  "  dixi)  (5-3.3) 

and  it  natural  to  state  our  objective  over  n  periods  to  be 

n 

Maximize:  I  (g^  "  dixi^  *  (5.3.4) 

i=l 

Combining  (5.3.1)  and  (5.3.2),  we  can  write  down  the  structural  matrix  as 
follows: 


and  let  A  be  the  column  vector  of  direct  variables  and  b  be  the  column 


vector  of  constraints,  i.e. 


—  — 

r  -i 

X1 

M 

1 

X 

x2 

M  -  I 

• 

I 

X 

M  -  I 

n 

.  b  - 

yi 

I 

y2 

I 

• 

• 

• 

yn 

1 

—  _ 

(5.3.6) 
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Furthermore,  if  we  denote  w  to  be  the  row  vector  of  dual  variables  t^'s  and 
u^'s  corresponding  to  x^'s  and  y^'s,  » 

w  -  t2  ...  tn  Uj^  u2  ...  u  ]  (5.3.7) 


then  we  can  write  down  both  the  Direct  formulation,  and  its  Dual, 
Linear  Programming  Problem  as: 

(1)  Direct  Problem 


Maximize: 

cX 

Subject  to: 

AX  < 

b. 

IV 

o 

(2)  Dual  Problem 

n  n 

Minimize : 

(M  - 

I) 

E  t  +  I  I 
i=l  i=l 

of  the 


(5.3.8) 


(5.3.9) 


Subject  to:  wA  -  c,  w  >  0 


where  c  is  a  row  vector,  i.e.. 


c  =  (-dL  -d2 


’dn  gl  g2 


gn] ' 


(5.3.10) 


5.3.3  Special  Method  of  Solution 

Rather  than  the  usual  Simplex  Method  for  solving  the  Direct  Problem, 
a  special  algorithm  can  be  employed  to  attack  the  Dual  Problem  instead,  due 
to  the  nature  of  this  problem  as  depicted  by  the  special  form  of  its  struc¬ 
tural  matrix  shown  in  (5.3.5).  Based  on  (5.3.5),  (5.3.9)  and  (5.3.10),  we 
can  establish  the  following  inequalities: 


t.  +  t„ 

+  .  .  . 

+ 

t 

+ 

0 

- 

"  U-  -  . . 

.  -  u  >  -d. 

1  2 

n 

2 

3 

n  1 

t„ 

+  .  .  . 

+ 

t 

+ 

0 

+  0  - 

u~  -  . . . 

-  u  >  -d_ 

2 

n 

3 

n  2 

+  tk+l  + 


+  t  +  0  +  0  + 


+  0  - 


\+l 


t 

n 


> 


-d 

n 
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ifii 


~C1  ~  *2  ‘  “  *n  +  U1  +  u2  + 

_t2  '  "  tn  +  0  +  u2  + 


+  un  -  81 

+  un  -  «2 


■‘k"  Ck+1  "  •••'“  tn  +  0  +  0+  ...  +0  +  Uk+  ...  +un  >  ^ 


-t 


+  u_  -  g_ 

n  n 


Summarily,  we  have 
n  n 


It-  I  u  >  -d  k  *  1,  2,  ....  (n-1) 
i-k  1  i-k+1  1  K 


(5 


n  n 

-It+  I  u  -  g  r  -  1,  2,  ....  n 

i-r  i-r  r 


(5 


where  t^,  -  0.  For  clarity,  we  will  define  two  new  variables..  Let 


\  "  A'* 

i-k 


U  -  I  U  . 
*  i-k  1 


(5 


Then  we  can  write  the  following  relations: 


T  , 

>  T 

r-1, 

2,  •  • • )  n 

r-1 

r 

Ur-1 

IV 

r-1. 

2  >  •  #  • »  n 

I  - 

t 

n 

n 

U  - 

u 

n 

n 

T-  - 

T 

0 

1 

n  - 

u. 

0 

1 

<5 


The  Dual  Problem  can  now  be  stated  in  terms  of  new  variables: 
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Minimize: 


ejyr.’jp.  v  jp 


Subject  to: 


where  k  »  1,  2,  . 


(M  -  I)  Tj  +  IUX 

<•>  Tk  -  Vl  '  \ 

<b>  Tn-'dn 
(O  Tk>Tk+1 

<d)  Uk+1  "  Tk+1  +  ®k+l 

<e)  Uk  "  Vl 

(f)  Tr,  U.  >  0 

«,  (n-1) ;  r  ■  lt  2,  *  n. 


(5.3.15) 


Clearly,  from  the  objective  function,  we  see  that  a  minimum  is  achieved 

by  finding  the  smallest  possible  values  of  T^  and  U^.  From  constraints  (a) 

through  (f)  in  (5.3.15),  that  Tj  and  can  be  found  alternately,  starting 

with  T  and  U  and  then  indexing  in  reverse  order.  In  each  step,  we  obtain 
n  n 

the  smallest  possible  values  for  Tk>  Uk>  i.e.,  bounded  from  below,  according 

to  the  appropriate  constraints.  The  process  is  briefly  illustrated  as  follows: 

From  (b),  (f)  of  (5.3.15), 

T  -  Max  t-d  ,  0); 
n  n 


From  (d),  (f ) , 


u  - 

Max  {(T  + 

g ),  0}; 

n 

n 

n 

From  (a) ,  (c) , 

(f>. 

T  . 

-  Max  (T  , 

(U  -d  ' 

n-1 

n 

n  n-1 

From  (d),  (e) , 

(f). 

U  , 

-  Max  {U  , 

(T  ,  +8 

n-1 

n 

n-1  n- 

T1 

-  Max  {T2, 

<W' 

U1 

•  Max  {Uj, 

(Tj  +  gj), 

The  entire  procedure  for  solving  the  minimizing  problem  of  (5.3.15)  is 
depicted  in  the  form  of  a  flow  chart  in  Figure  5.3. 
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fit*  5.3.  Flow  chart  of  tha  procedure  for  solving  the  special  * in lairing 
problea 
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5. 3. A  A  Special  Class  of  Solutions 


Since,  at  each  stage,  the  T^s  and  U^’s  are  determined  from  tvo  or 
more  values,  a  general  solution  in  terms  only  of  the  literals  of  'a  and 
d^'s  cannot  be  obtained  unless  the  specific  relations  between  then  are  known 
beforehand. 

In  each  step,  there  is  always  a  zero  as  a  possible  lower  bound,  due  to 

constraint  (f)  or  (5.3.15).  This  is  really  redundant  because  there  is  always 

a  T^  or  in  the  possible  choices  for  T^_^  or  with  the  exception  of  Tfl 

and  U  .  Also  be  (f),  we  have  T. ,  U.  t  0.  Furthermore,  d  's  and  g. 's  are 
n  11  11 

always  positive.  Even  though  we  have  stated  earlier  that  these  are  artificial 
quantities,  it  would  not  be  reflecting  any  reality  to  consider  any  negative 
cost  and  negative  gain.  Combining  these  "natural"  conditions,  we  may  obtain 
a  special  class  of  solutions  by  imposing  some  additional  conditions. 


(5.3.16) 


o  ^  d 
gi+l  i 


i.e.,  the  gain  per  unit  memory  for  the  current  and  next  period  is  at  least 
as  much  as  the  cost  per  unit  memory  for  the  current  period. 

From  constraint  (a)  of  (5.3.15),  we  have 


Tk  -  Vi  -  "k  ’ 

and  from  constraint  (d) ,  we  have 

Uk+1  -  Tk+1  +  ®k+l  * 

Combining  these  two  inequalities,  we  obtain 

Tk  “  Tk+1  +  <8k+l  "  * 

Since,  from  (5.3.16),  we  know  that 

<*k-V*°  • 

This  implies  that  if  (a)  and  (d)  are  true,  then  (c)  is  always  true. 
Furthermore , 

Uk+1  "  \  ~  Tk+1  +  (8k+l  "  V 


implies  that 


\+l  "  \  ~  Tk+1 


(5.3.17) 


From  Figure  5.3,  we  see  that 

T.  -  M.X  (I,.,. 


<0k+i-V>- 


Therefore,  utilizing  (5.3.17),  we  obtain 

Tk  -  Vx '  "k 

for  k  ■  1,  2,  ....  (n-1)  . 
Similarly,  we  have 


“k  2  \  +  *k  2  Vi  -  "k  ♦  «k 


(5.3.18) 


which  implies  that 

Tk  +  -  Vi  • 

Again,  from  Figure  5.3,  we  see  that 

”k  ■  "W 

and  utilizing  (5.3.19),  we  obtain 
Uk  “  Tk  +  «k 

for  k  ■  1,  2,  ....  (n-1). 

The  values  thus  obtained  for  the  T^'s  and  U^'s  are: 

T  -  0 
n 

Un“8n 

Tn-1  8n  dn-l 
n-1  n-1  n-1 

"  8n  +  8n-l  *  Cn-1 

Tn-2  "  8n  +  8n-l  “  dn-l  "  dn-2 

Un-2  "  gn  +  8n-l  +  gn-2  '  dn-l  "  dn-2 

Tn-3  8n  +  8n-l  +  gn-2  "  dn-l  dn-2  dn-3 

Un-3  "  8n  +  8n-l  +  gn-2  +  gn-3  “  dn-l  "  dn-2  *  dn-3 


(5.3.19) 


(5.3.20) 


T1  *  8n  +  8n-l  +  ’ * •  +  «2  “  dn-l  '  dn-2 


.  -  d. 


-  I  8,"  I  di 

i-2  1  i-1 


/-K  .  >. 


°1  "  8n  *  8n-l  + 


•  e  •  + 


*2  +  81  **n-l  ”  ^n-2 


•  •  •  •  d. 


-  I  8t  -  E  d 

i-1  1  i-1  x 


The  objective  function  has  the  following  value: 


(H  -  I)T  +  IU  -  (M-I)(  Eg  -  E  d.) 

i-2  1  i-1  1 


+  I(  E  g.  -  E  d.) 
i-1  1  i-1  1 


-  M(  E  g  -  E  d  )  +  Ig. 
i-2  1  i-1  1  1 


(5.3.21) 


If  we  are  only  interested  in  obtaining  the  optimum  value  of  the  objective 
function,  then  our  task  is  done.  However,  we  are  interested  in  the  optimal 
"loading  and  processing"  strategy  which  would  achieve  such  an  optimum  value 
of  the  objective  function.  In  other  words,  we  need  to  know  the  solutions  in 
terms  of  the  direct  value,  i.e.,  x^'s  and  y^'s.  If  the  objective  function 
for  the  Direct  (Maximizing)  Problem  is  denoted  by  it  and  if  its  Dual  (Mini¬ 
mizing)  is  denoted  by  E,  then  the  Duality  Theorem  (see  Chapter  4,  Section 
4.4.6)  states  that 

Max  tt  -  Min  E. 

This  is  to  say  that  the  two  objective  functions  are  equal  at  the  optimum. 
Therefore,  , 


1  8iyi 
i-1 


E  d  x  -  Ig  +  E  g  M  -  E  d  M 
i-1  1  i-2  1  i-1  1 


By  equating  coefficients  term-by-term,  we  obtain: 


yx  -  i; 


M,  i-2,  3,  ....  n; 

M,  i  -  1,  2,  ... ,  n-1; 


(5.3.22) 


x  -  0  . 

n 

There  is  a  rather  straightforward  interpretation  of  this  result:  the  optimui 
strategy  for  the  best  utilization  of  a  given  memory  space  over  a  period  of 
time  is  simply  to  load  program  space  up  to  the  maximum  capacity  and  then  to 
process  all  programs  in  the  memory.  An  Immediate  consequence  to  this  result 


r 


is  that  the  preemption  of  any  program  is  not  desirable  since  it  deviates 
from  the  optimum  memory  utilization  plan.  In  reality,  the  optimum  might 
not  always  be  achievable  due  to  the  fact  that  memory  cannot  always  be  packed 
full. 

5.3.5  Numerical  Illustration 

Let  us  consider  the  memory  usage  question  of  five  periods,  with  the 
cost  and  gain  in  each  period  as  given  in  Table  5.10.  The  total  memory 
capacity  is  200  units  and  prior  to  period  1,  100  units  of  memory  space 
had  been  occupied. 

Notice  that  the  costs  are  identical  in  every  period.  Also,  it  should 
be  clear  that  these  cost  and  gain  figures  have  no  absolute  meaning;  only 
their  relative  magnitudes  may  reflect  upon  our  system  policy.  We  will 
explain  this  point  later  on. 

The  detailed  computations,  according  to  the  procedures  outlines  in  the 
last  section,  are  as  follows: 

Tj  *  Max  {-dj,  0} 

-  Max  (-20,  0} 

»  0 

U5  -  Max  {(T5  +  g5),  0} 

-  Max  {(0  +  50),  0) 

-  50 

T4  -  Max  {T5,  (U5-  d4),  0) 

-  Max  {0,  (50-  20)} 

-  30 

°A  *  Max  {V  <T4  +  84)} 

•  Max  {50,  (30  +  40)} 

-  70 

T3  -  Max  {T4.  (U4-d3)} 

-  Max  {30,  (70-20)} 

-  50 


94 


Table  5.10  An  example  with  five  perioda 


U3  -  Max  {U4,  (T3  +  g3)} 

-  Max  {70,  (50+21)} 

»  71 

T2  -  Max  {T3,  (U3-d2)} 

-  Max  {50,  (71-  20)} 

-  51 

02  -  Max  {U3,  (T2  +  g2)} 

-  Max  {71,  (51+35)} 

■  86 

T3  -  Max{T2,  (U2-d1)} 

-  Max  {51,  (86-20)} 

■  66 

U3  -  Max  {U2,  (T1  +  g1)} 

-  Max  {86,  (66  +  25)  } 

-  91 

The  best  possible  net  gain  for  the  memory  system  over  this  five  periods  is 
therefore 

(M  -  I)T1  +  1UX  -  (200  -  100) *66  +  100*91 
-  15700. 

This  gain  is  a  rather  artificial  one.  What  concerns  us  here  is  the  strategy 
with  which  this  optimum  gain,  whatever  that  may  be,  can  be  achieved.  In 
order  to  obtain  this  optimal  program,  i,e.,  plan,  we  should  revert  back  to 
the  direct  variables. 

Note  that  the  values  of  d^'s  and  g^'s  satisfy  (5.3.16),  hence  we  may 
utilize  the  result  stated  in  (5.3.21),  l.e., 

n  n-1 

(M  -  I)T  +  IU.  -  M(  Z  g  -  I  d.)  +  Ig.  . 

1  i-2  1  i-1  1  1 

Since  this  optimum  value,  of  the  minimizing  problem,  is  equal  to  the  maximizing 

problem,  due  to  the  Duality  Theorem,  we  have,  for  n-5,  M-  200,  I"  100, 

5  5  4 

Z  (g.y.  -d.x.)  -  200  (  Eg.  -  Z  d.)  +  100g.  . 
i-1  1  1  1  i-2  1  i-1  1  1 
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By  equating  coefficients  term-by-term,  we  obtain  in  Figure  5.4  a  processing- 
loading  pattern  which  is  optimal  in  the  sense  as  defined  by  (5.3.4). 

If  we  modify  slightly  the  values  given  in  Table  5.10,  the  resultant 
"program"  might  change  accordingly.  Suppose  g2  has  a  value  of  17  instead 
of  35,  it  can  be  shown  that 

U2  -  Max  (U3,  (T2  +  g2)> 

“  U3 

-  71 

T2  -  Max  {T2,  (Uj-dj)} 

-  51 

Ux  -  Max  (U2,  (T1  +  g1)} 

-  76 

(M  -  I)T1  +  IUX  =  (200  -  100) *(51)  +  (100) *(76) 

-  12700 

and  the  optimal  pattern  is  shown  in  Figure  5.5. 

We  see  that  period  2  is  inactive  since,  according  to  the  criterion,  it 
is  not  profitable  to  do  any  processing  work.  This  is  due  to  the  fact  that 
d2  >  82  and  therefore  U2  *  Instead  of  U2  "  T2  +  82*  Thus»  carrying  on 
with  the  solution  process,  g2  is  missing  from  all  the  subsequent  steps  and 
there  is  no  g2  term  in  the  final  minimum  objective  functional.  Hence,  when 
we  equate  coefficients  with  the  maximum  objective  functional,  the  corresponding 
term  g2y2  *s  etlua-*-  to  zero.  This  forces  y2  to  be  zero,  i.e.,  no  processing 
activity  in  period.  Clearly,  the  above  analysis  holds  true  that  if  for  any 
period  i,  i  4  1,  d^  >  g^,  then  during  that  period  there  will  be  no  processing 
in  the  final  optimum  plan.  In  the  extreme  case  that  d^  >  g^  for  all  1,  then 
optimal  strategy  is  simply  to  process  everything  already  in  the  memory,  i.e., 
the  Initial  load,  and  stop.  In  short  it  is  no  longer  advantageous  to  continue 
to  operate  the  memory  system  under  such  circumstances.  Or,  viewed  differently, 
the  entire  productive  system  (processor  and  memory)  in  this  case  cannot  satis¬ 
factorily  carry  out  the  processing  demand  according  to  some  predetermined 
performance  criterion. 
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Period 


Processing 


Loading 


100  200  200  200  200 

200  200  200  200  '  0 


Fig.  5.4  Optimum  processing-loading  patterns  for  five  periods 


Fig.  5.5  Optimum  processing-loading  pattern  with  period  2  inactive 
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This  represents  a  more  typical  multiprogramming  environment,  where 
different  user  programs  have  different  sizes.  We  will,  based  upon  the 
ideas  and  results  propounded  in  the  immediately  prior  sections,  inquire 
into  some  possible  scheduling  disciplines. 

Let  us  assume  that  there  are  m  different  programs  loaded  into  memory 
to  be  processed,  each  with  size  1^  units,  I^I^  -  M.  If  we  partition  the 
memory  space  exactly  according  to  each  1^,  then  we  may  view  the  system 
as  having  m  independent  memory  sections  or  more,  each  with  a  capacity  of 
1^  units,  with  the  possible  exception  being  that  portion  of  the  memory  space 
where  no  program  can  fit  in.  Furthermore,  each  section  is  full;  except 
the  fragmented  portion,  which  is  empty.  Each  individual  section  can  now 
be  viewed  as  similar  to  the  problem  treated  in  Section  5.3.2,  but  with  only 
one  program  and  such  that  this  program  takes  up  the  entire  available  space. 

Now  we  will  redefine  the  notion  of  "period".  Recall  that  in  Chapter  4, 
Section  4.2,  we  briefly  described  the  processing  action  of  the  processor 
in  a  multiprogrammed  situation.  A  program’s  processing  can  be  delayed 
cue  either  to  I/O  activity  or  through  timer  interrupt.  Therefore,  the 
processor  is  being  switched  among  all  the  resident  programs  based  on  either 
a  cyclic  rule  or  some  "dynamic"  discipline.  If  it  is  cyclic,  then  it 
requires  no  decision  on  the  part  of  the  system,  once  all  the  programs  are 
in  memory  and  the  system  ready  queue  is  thus  formed.  However,  because  of 
the  unpredictable  nature  in  terms  of  timing  of  I/O  activities,  a  program 
may  not  always  be  able  to  continue  even  though  the  processor  has  made  its 
"rpund"  and  back  again.  In  this  case,  the  particular  program  is  being 
"skipped"  for  the  time  being.  The  definition  can  now  be  stated  as: 

Definition  5.1:  A  period  for  program  i  is  the  time  between 
1)  processor  entering  and  leaving  (active),  or  2)  leaving  and 
returning  (delayed),  or  3)  a  skip,  of  program  i. 

Note  that  we  consider  that  the  processor,  after  entering  a  program  and  upon 
Interrogating  the  condition,  deciding  not  to  stay,  to  be  a  skip.  Note  also 
that  periods  defined  this  way  are  possibly  of  unequal  length  within  a  program 
and  among  programs. 

The  objective  function  for  the  entire  system  of  m  programs  over  n 
periods  can  be  stated  as : 


(5.3.23) 


Maximize:  I  Z  (g  .  -  d  )I  (5.3.23) 

j-1  i-1  3  3 

where  g^  is  the  gain  for  program  i  in  period  j  and  d^  is  the  cost  for 
program  i  in  period  j.  Clearly,  the  best  (optimal)  strategy  is  that  for 
all  i,  process  those  programs  for  all  j  such  that  g  >  d^ ,  and  skip  if 
otherwise.  This  is  a  direct  extension  of  the  results  discussed  in  Section 
5.3.4.  If  we  follow  this  approach,  then  the  scheduling  discipline  is  clearly 
decided  upon  by  the  relative  magnitudes  of  g^'s  and  d^’s.  Previously,  we 
stated  that  a  particular  program  may  be  skipped  over,  possibly  due  to  some 
"natural"  causes  such  as  waiting  for  I/O  completions.  By  defining  our 
objective  function  as  (5.3.23)  and  following  the  optimal  plan,  it  is  possible 
to  exert  dynamic  control  over  the  scheduling  activities  by  manipulating 
g^’s  and  djj's. 

5.3.7  Considerations  for  g^ *s  and  d^ 's  and  Scheduling  Discipline 

We  have  pointed  out  earlier  that  both  the  gain  and  the  cost  of  a 
particular  program  are  something  rather  intangible  and  the  values  chosen 
to  quantify  them  are  Indeed  artificial.  However,  artificiality  does  not 
imply  arbitrariness.  We  certainly  would  like  to  consider  the  relevant 
factors  in  choosing  their  values  so  that,  in  the  final  analysis,  the 
scheduling  disciplines  thus  resulting  constitute  viable  actions. 

(1)  d^  ■  d^  for  all  j;  that  is,  the  cost  per  unit  memory  for 
program  i  does  not  change  according  to  period  j .  Let  us  further 


denote  that  dj 


di*  We  would  consider  this  cost  as  a  function  of 


both  the  program  size  and  memory  speed,  i.e., 

^  p) 

where  1^  is  the  size  of  program  i  and  p  is  the  speed  of  the  memory. 

On  first  glance,  it  would  seem  redundant  to  Include  1^  as  a  parameter 
since  d^  is  already  the  cost  of  per  unit  memory.  But,  upon  closer 
examination,  this  definition  would  give  us  the  freedom  to  "favor" 
programs  according  to  their  sizes.  For  example,  if  we  define  d^ 
to  be  , 


!i  ■  V,n  “ 


constant 
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Chen  Che  smaller  program  will  be  favored  since  Che  cosC  will  be 
higher  for  Che  larger  programs.  Also,  defined  as  above,  d^  is 
inversely  proporclonal  to  p,  Che  memory  speed,  in  unics  of  time  and 
Che  higher  Che  speed,  Che  higher  che  cosC  of  d^.  There  are,  of 
course,  many  possible  choices  of  relevanC  parameters  and  many  possible 
functionals.  We  only  suggest  one  here  so  as  to  illustrate  a  point. 

(2)  Recall  chat  in  previous  sections  we  have  discussed  the  "loading 
activity"  of  the  system,  based  on  the  concept  of  generalized  value 
c^  for  program  i,  and.  we  will  utilize  this  value  to  start  the  sched¬ 
uling  cycle.  Specifically: 

i)  Let 

ii)  If  at  period  j,  program  i  is  being  skipped  over, 
then  for  period  (j  +  1) ,  set 

gi(j+l)  “  8ij  +  Ydi  °  "  Y  5  1* 

This  reflects  the  thinking  that  every  time  a  program  is 
being  skipped,  rather  than  increasing  the  cost  of  resi¬ 
dency,  we  instead  think  of  it  as  being  potentially  more 
valuable,  i.e.,  higher  gain,  to  process  this  program  at 
a  possible  earlier  time.  Therefore,  we  increase  its 
gain  per  unit  memory  proportional  to  its  cost  for  the 
next  period.  Hence,  the  dynamic  nature  is  reflected  in 
the  monotonicity  of  g^  while  d^^  remains  constant. 

A  possible  scheduling  discipline  is  as  follows: 

In  period  J,  select  the  job  with  the  highest  g^  among  all 

i  such  that  g^  >  d^  to  be  processed. 

We  will  make  these  remarks  regarding  this  particular  scheduling 
discipline : 

i)  It  is  priority  influenced  since  g^  ■  c^  and  c^  is  the 
generalized  value  for  program  i  which  can  be  directly 
related  to  priority  classes. 

ii)  No  program  will  be  skipped  indefinitely  since  g^  is 
monotonically  increasing  and  will  be  processed  even¬ 
tually.  In  a  way,  this  is  dynamic  readjustment  on 
priority  while  the  choice  of  c^  is  static. 


I 


ill)  The  actual  schedule  depends  on  the  function  $  and  also 
the  constant  y.  Specificity  cones  only  with  specific 
system. 


\ 
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CHAPTER  VI 


Program  Characteristics  and  Memory  Allocation 
Considerations  in  Page-on-Demand  Systems 

6.1  Introduction 

In  a  paged  environment,  a  task  is  allocated  a  memory  size  (primary) 
smaller  than  its  entirety.  Sooner  or  later,  a  data  item  will  be  referenced 
which  is  not  found  in  the  allocated  space.  This  causes  a  page  fault.  A 
process  will  then  be  initiated  to  locate  and  bring  the  missing  page  from 
secondary  into  the  primary  memory.  During  this  period,  the  processor  is 
potentially  non-productive;  the  longer  and/or  the  more  frequent  this  period 
directly  reflects  the  deficiency  of  the  system. 

If  we  exclude  I/O  activities,  then  the  frequency  (or  page  fault  rate) 
with  which  processor  idling  takes  place  is  a  function  of  two  different 
categories  of  parameters:  1)  user  profile,  and  2)  operating  system  design. 
The  duration  (page  wait)  is  a  function  of  system  configurations,  i.e.  band¬ 
width  of  the  data  channel  between  primary  and  secondary  memory,  and  the 
decision  of  operating  system  design,  i.e.,  amount  of  data  items  (page  size) 
to  be  brought  into  primary  memory.  And  if  the  secondary  memory  is  of  the 
rotational  kind  such  as  disc,  then  the  time  delay  due  to  latency  should 
also  be  taken  into  consideration. 

Let  us  examine  the  two  categories  of  parameters  that  influence  the  page 
fault  rate. 

1)  User  Profile  -  This  involves  the  particular  problems  on  hand 
(applications),  the  specific  instruction  sets  available,  and  finally,  the 
individual  coding  style.  The  combination  of  these  factors  produces  addressing 
patterns  that  can  be  characterized  as  having  certain  clustering  effects  on 
various  portions  of  the  total  addressing  space;  namely,  in  a  given  part  of 
the  program,  the  execution  is  likely  to  proceed  in  a  sequential  manner  (maybe 
even  jumping  backward  a  few  steps  such  as  in  a  loop)  for  a  period  of  time  and 
then,  when  a  branch  instruction  is  encountered,  moves  on  to  a  different  locale 
which  may  be  quite  a  "distance"  away.  Thus,  if  we  examine  the  dynamic  foot¬ 
prints  (addresses)  of  a  processor,  they  tend  to  cling  together  and  form 
clusters  and  move  from  cluster  to  cluster  and  finally  gravitate  towards  the 
end,  i.e.,  termination  of  the  program.  We  may  look  upon  this  phenomenon  as 
"addressing  non-uniformity".  Or,  equivalently  speaking,  the  processor  time 
is  non-uniformly  distributed  over  the  addressing  space. 


2)  System  Parameters  -  In  regard  to  the  page  fault  rate,  the  page  size 
is  an  important  factor.  If  the  size  is  too  small  with  respect  to  the  address 
clusters,  we  would  expect  a  high  page  fault  rate;  if  too  large,  memory 
utilization  is  low  since  a  processor  only  needs  those  data  items  within  a 
cluster  most  immediately. 

Addressing  nonlinearity  is  something  beyond  the  control  of  system 
designers.  The  only  influence  we  can  exercise  is  the  determination  of  the 
page  size  and  the  number  of  pages  to  be  assigned  to  a  given  task.  On  the 
one  hand,  we  would  like  to  minimize  the  page  fault  rate,  therefore  high 
processor  utilization;  on  the  other  hand,  we  would  also  like  to  minimize 
the  memory  waste  by  only  loading  those  pages  that  are  needed  immediately 
and  in  the  near  future.  Clearly,  these  two  goals  are  conflicting  with  each 
other.  In  order  to  strike  a  balance  between  the  two,  page  size  and  the 
number  of  pages  loaded  must  be  determined  from  the  characteristics  of  the 
address  clusterings.  This  is  a  brief  summary  of  the  motivation  and  the 
problem  associated  with  the  automated  memory  management  in  a  hierarchical 
memory  structure,  page-on-demand  computer  environment.  Of  course,  the 
problem  will  be  immensely  simplified  if  there  exists  a  priori  knowledge  of 
the  complete  addressing  pattern  of  each  individual  program;  this  is  hardly 
a  reality,  however.  After  all,  in  the  core  of  the  user  profile  is  the  matter 
of  personal  coding  style  which  is  such  an  intangible  entity.  We  have  already 
touched  upon  the  subject  of  dynamic  processor  footprints  and  address  non¬ 
linearity  in  general.  Working  Set  in  particular,  in  Chapter  3.  In  this 
chapter  we  will  expound  on  the  subject  of  possible  analytic  representation 

i 

on  this  nonlinear  property.  That  is,  an  analytic  function  which  characterizes 
the  mean  time  between  page  fault,  in  a  demand  paging  environment.  Possible 
memory  allocation  policy  based  on  this  characterization  is  explored. 

6.2  Address  Nonlinearity,  Program  Locality  and  General  Lifetime  Function 

Belady  [39]  first  proposed  that  address  nonlinearity,  or  program  local¬ 
ity,  is  the  total  range  of  storage  references  during  a  given  execution 
interval.  Denning  [30]  has  termed,  in  a  demand  paging  machine,  the  collec¬ 
tion  of  pages  in  a  given  execution  interval  to  be  the  Working  Set.  Due 
to  this  reference  nonuniformity,  it  is  to  be  expected  that  the  page  fault 
rate,  or  alternately,  the  mean  time  between  page  fault  aa  a  function  of 
allocated  apace,  assumes  a  nonlinear  relationship.  This  nonlinear  property 


106 


46*  ' 


has  been  observed  and  reported  by  Belady  [39]  and  others  [40.41].  In  order 
to  formulate  and  to  study  analytically  some  of  the  system  parameters  under 
space  sharing,  Belady  and  Kuehner  [42]  proposed  an  analytic  function,  the 
Lifetime  Function,  which  describes  the  nonlinear  relationship  between  the 
page  fault  rate  and  allocated  space.  The  following  discussion  will  pursue 
this  idea  for  the  most  part. 

6.2.1  Lifetime  Function  and  Some  of  Its  Properties 

Figure  6.1  depicts  an  "observed"  relationship  between  the  averaged 
processor  busy-period  as  a  function  of  the  allocated  memory  space.  The 
busy  period  is  the  time  between  two  consecutive  page  faults;  I/O  interrupts 
are  not  represented. 

S  represents  the  total  space  required  to  load  the  entire  program, 

K 

hence  no  page  faults,  and  tD  is  the  execution  time  for  the  program.  There 
are  two  more  interesting  points  on  this  curve,  that  of  P  and  Q.  For  a 
memory  allocation  less  than  Sp,  the  value  corresponds  to  P,  the  corresponding 
processor  busy  period,  i.e.,  mean  time  between  page  faults,  is  very  short, 
therefore  resulting  in  high  paging  rates.  This  is  the  OP  region.  Within 
the  PQ  region,  that  is  if  the  memory  space  falls  between  Sp  and  S^,  the 
length  of  the  processor  busy  period  increases  rather  rapidly  as  the  amount 
of  memory  space  allocated  increases.  If  the  allocated  space  S  increases 
beyond  Sp,  the  QR  ragion  is  reached  and  the  rate  of  increase  in  T  slows 
down  as  compared  to  the  PQ  region.  The  behavior  of  the  Lifetime  Function 
in  the  QR  region  is  perhaps  less  intuitive  than  that  of  the  OP  region. 

However,  if  we  view  this  from  the  concept  of  address  clusterings,  it  should 
become  quite  clear.  As  discussed  earlier,  most  of  the  time  during  program 
execution,  the  instructions  being  executed  tend  to  bunch  together.  The 
most  obvious  example  is  the  DO-loop  type  of  execution  sequences.  The  entire 
execution  of  a  program  can  be  looked  upon,  in  an  abstract  sense,  as  being 
the  dynamic  foot-prints  of  the  processor  which  goes  through  a  string  of 
address  clusterings.  Also,  there  are  differences  in  the  size  of  the  indi¬ 
vidual  clusters.  Let  us  say  that  the  allocated  space  Sp  is  smaller  than  the 
sizes  of  most  of  the  address  clusterings.  Then,  clearly,  the  processor  will 
be  interrupted  more  frequently,  due  to  missing  items  from  the  primary  storage. 
On  the  other  hand,  if  is  greater  than  the  sizes  of  most  of  the  clusters 
in  a  program,  then  any  space  allotment  beyond  that  point  would  not  signifi¬ 
cantly  lower  the  probability  of  page  faults,  and  therefore  a  lower  rate  of 
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increases  in  the  average  length  of  processor  busy  period,  T. 

If  we  were  to  utilize  these  properties  to  come  up  with  an  algorithm 
for  memory  assignment,  clearly  we  must  reckon  with  these  two  special  points, 

F  and  Q.  Let  us  call  them  the  "knees"  of  the  Lifetime  Function.  Their 
corresponding  memory  sizes,  Sp  and  Sp,  are  the  actual  parameters  we  should 
be  concerned  with.  Before  we  can  say  that  any  algorithm  is  optimum,  we 
must  first  specify  what  is  optimality  and  the  norm,  or  performance  index, 
by  which  it  can  be  measured.  The  most  commonly  pursued  system  resources 
management  objectives  are  that  of  increasing  processor  productive  period 
and  memory  utilization.  Of  course,  these  two  goals  are  neither  mutually 
enhancing  nor  conflicting;  it  depends  upon  the  system  policy.  Generally, 
the  way  to  increase  utilization  of  the  processor  is  to  increase  the  degree 
of  multiprogramming;  this  will  also  tend  to  shorten  the  turn-around  time 
from  the  users'  point  of  view.  Since  not  all  of  the  program  addressing  space 
needs  to  reside  in  memory  at  the  same  time,  all  programs  are  loaded  in  space¬ 
squeezing  fashion.  Given  the  fixed  size  of  primary  memory,  the  individual 
program  memory  allotments  determine  the  degree  of  multiprogramming  which  in 
turn  influences  the  processor  utilization.  From  this  brief  discussion  with 
a  simplified  framework,  e.g.,  excluding  I/O  considerations,  we  see  that 
the  important  parameter  is  the  size  of  the  memory  for  each  Initial  program 
loading.  From  the  Lifetime  Function  as  portrayed  in  Figure  6.1,  we  may 
discern  that  for  a  memory  allocation  of  S  -  Sp  is  clearly  undesirable  since 
it  produces  high  page  fault  rates.  For  S  »  Sp,  the  increase  in  the  average 
length  of  processor  busy  period  may  not  be  enough  to  warrant  the  additional 
amount  of  memory  invested  in.  We  may  thus  decide  that  for  an  individual 
program,  the  memory  space  allotted  to  it  should  at  least  be  Sp  and  not  much 
beyond  Sp.  Of  course,  we  have  not  as  yet  defined  precisely  where  these  two 
points  are  on  the  T  vs  S  curve,  or  which  point  on  this  curve  should  be 
chosen  as  an  allocation  point. 

In  the  foregoing  discussions,  we  have  put  aside  the  question  of  page 
replacement;  the  page  fault  rate  is  considered  to  be  a  function  of  memory 
space.  Actually,  the  page  replacement  algorithms  also  contribute  to  the 
page  faults  in  the  form  of  return  page  traffic  rate.  The  term  "return 
traffic"  was  first  used  by  Denning  in  the  discussion  of  the  Working  Set 
Model.  In  a  space-limited  environment,  each  new  page  coming  in  must  result 
in  another  page  going  out.  If  this  page  of  information  is  needed  at  a  later 
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time,  it  must  be  loaded  back  again,  constituting  the  "returning"  traffic. 

If  the  choice  of  the  page  to  be  replaced  is  poor,  then  the  returning  traffic 
is  "relatively"  heavy,  and  therefore  the  processor  busy  period  is  relatively 
short.  This  problem  is  not  a  basic  program  property  and  is,  rather,  the 
consequence  of  some  artificial  decisions,  i.e.,  replacement  algorithms. 
Certainly,  a  good  decision  would  minimize  such  return  traffic.  A  poor  one 
could  cause  the  system  to  collapse.  This  problem  was  studied  by  Denning  [43] 
and  also  observed  by  some  others  in  actual  systems  [44].  For  the  moment,  we 
are  interested  in  the  intrinsic  program  addressing  property  as  related  by 
processor  busy  period  and  its  allocated  memory  space.  In  summing  up,  the 
general  remarks  one  can  make  are:  The  Lifetime  Function  exhibits  some 
nonlinearity;  the  "saturation"  characteristic  is  due  to  program  locality, 
and  the  processor  busy  period  is  monotonically  increasing  as  a  function  of 
memory  space. 

6.2.2  Analytic  Representation  of  the  Lifetime  Function 

The  basic  parameters  in  the  Lifetime  Function  are  discrete  in  nature. 

In  fact,  when  one  talks  about  memory  allocation,  the  unit  is  either  in  blocks 
or  pages,  due  to  the  nature  of  system  hardware  design.  In  attempting  an 
analytic  form,  we,  in  effect,  have  treated  the  memory  allocation  as  a  problem 
with  a  continuous  variable.  This  should  in  no  way  nullify  the  important 
characteristics  and  rather  it  affords  us  the  advantage  of  some  mathematical 
tools. 

Before  going  into  more  specific  forms,  let  us  first  consider  some 
possible  representations  of  the  Lifetime  Function  under  two  adverse  assump¬ 
tions;  that  the  program  addressing  pattern  is  either  1)  purely  random,  or 
2)  strictly  sequential. 

1)  Purely  Random 

Let  R  »  total  range  of  program  addressing  space 
S  -  allocated  space  for  that  program 
where  R  >  S  . 

For  a  random  referencing  pattern,  let  P  be  the  probability  that  the  referenced 
item  falls  within  the  allocated  space.  Then 


Let  x  be  the  number  of  consecutive  references  to  the  allocated  space, 

then 
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Pr[x  -  1]  »  p(l  -  p) 

*  Probability  of  exactly  one  reference  before  it 
went  out  of  the  allocated  range,  hence,  page  fault 


Similarly, 


Pr [x  -  (n-1) ] 


Pr [x  «  n]  =  p  (1  -  p) 

If  T  is  the  mean  time  between  page  faults,  in  units  of  memory  references 


then 

T  *  Iipi(l  -  p)  i  *  1,  2,  3,  ... 
i 

*  p(l  -  p)  +  2p2(l  -  p)  +  3p3(l  -  p)  +  4p4(l  -  p)  +  ... 

2  2  3  3  4  4  5 

*  p  -  p  +  2p  -  2p  +  3p  -  3p  +  4p  -  4p  +  . . . 

2  3  4 

=p+p  +p  +p  +... 

-  p(l  +  p  +  p2  +  p3  +  ...) 


_ E _ 

(1  -  P) 


s 

R 


We  have  obtained  an  expression  for  the  mean  time  between  page  fault  as 
a  function  of  allocated  space.  Clearly,  this  is  a  convex  function.  To  see 
this,  we  only  have  to  examine  its  derivative 
dT  (R  -  S)  +  S 
dS  ’  (R  -  S)2 
R 

*  2 

(r  -  sr 

which  is  monotonically  increasing  as  S  increases,  within  the  meaningful  range 
of  S  <  R.  The  function  is  plotted  in  Figure  6.2.  For  S  -*•  R,  we  T  -*•  <*>.  In 
other  words,  when  the  entire  program  is  in  memory,  there  is  no  page  fault. 

2)  Strictly  Sequential 

If  the  processor  fetches  and  executes  information  item  by  item,  in 
sequence,  then  the  execution  time  before  a  page  fault  occurs  will  be  linearly 
proportional  to  the  amount  of  memory  space  allocated.  Assuming  that  the 
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memory  size  is  in  units  of  information  item  per  fetch,  e.g.,  a  word,  or  a 
number  of  bytes,  then  in  strictly  sequential  case,  an  allocation  of  memory 
size  S  means  that  a  processor  can  access  memory  S  times  before  a  page  fault. 
The  Lifetime  Function  would  then  be  a  simple  straight  line  with  slope  of 
unity.  In  general,  we  can  represent  this  function  as  a  straight  line  with 
slope  1/m  where  m  is  the  amount  of  information  items  per  fetch,  in  memory 
units.  For  example,  if  we  choose  to  represent  memory  size  in  units  of  bytes 
and  in  each  access  to  memory  2  bytes  will  be  fetched  and  executed,  then  m  »  2 
This  is  illustrated  in  Figure  6.3. 

These  two  cases  represent  the  two  extremes  in  program  addressing 
patterns.  Of  course,  a  real  life  program  does  not  proceed  in  purely  random 
fashion  nor  will  it  be  in  a  strictly  sequential  manner.  There  are  some 
additional  properties  pertaining  to  them  which  are  peculiar.  The  mean  time 
between  page  faults  in  the  pure  random  case,  is  just  what  the  term  implies: 
a  mathematical  expectation  for  a  given  space.  The  replacement  algorithm  has 
no  effect  on  its  overall  T.  In  other  words,  page  fault  rate  is  not  affected 
by  which  old  page  is  chosen  to  be  replaced  with  a  new  page,  since  the 
addressing  is  random  and  the  probability  of  a  page  fault  is  only  a  function 
of  the  space  allocated.  This  holds  throughout  the  entire  program  execution 
interval.  In  the  sequential  case,  T  is  deterministic  and  the  replacement 
policy  also  has  no  effect  on  it;  in  fact,  T  is  constant  but  of  different 
value  from  the  initial  one  after  the  first  page  fault.  In  other  words,  if 
is  the  initial  program  lqpd  size,  T^  =  S^/m.  If  each  page  is  of  size 
Then  after  a  page  fault,  a  new  page  is  brought  in  to  replace  an  old  one.  The 
execution  interval  then  and  thereafter  will  always  be  T2  =  S^/m,  irrespective 
of  replacement  policy,  and  T^  >  T^  since  >  $2- 

By  and  large,  a  program  would  normally  follow  the  instructions  in 
sequence  until  it  comes  to  a  branch  instruction.  At  this  point  there  are 
two  possibilities:  branch  forward  or  backward.  A  backward  jump  constitutes 
a  program  loop.  This,  to  a  degree,  serves  to  reinforce  the  effect  of  address 
clustering,  i.e.,  increasing  the  mean  time  between  page  faults  for  a  given 
space  allocation.  A  forward  jump  effectively  reduces  the  portion  of  the 
program  that  is  executed  sequentially,  hence,  the  length  of  the  processor 
busy  period.  The  picture  is  further  complicated  by  the  fact  that  it  is 
possible  to  jump  back  after  jumping  forward,  i.e.  nested  loop  of  sorts,  and 
jumps  out  in  the  middle  of  the  loop  the  second  time  around,  to  a  point 
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further  down  the  line  of  the  execution  sequence.  Branching  is  an  inevita¬ 
bility  with  which  we  must  reckon.  For  a  given  problem,  the  final  program, 
or,  more  to  the  point,  the  final  structure  of  all  the  "branches"  is  really 
a  matter  of  individual  style.  Therefore,  a  desirable  representation  of  the 
program  Lifetime  Function  not  only  should  explicitly  represent  its  nonlin¬ 
earity,  i.e.,  the  two  "knees”  on  the  curve,  which  is  the  result  of  address 
clustering,  or  locality,  but  also  in  some  way  reflects  a  degree  of  randomness, 
or  the  so-called  personal  styles.  In  summing  up,  perhaps  we  can  lay  down 
some  guidelines  as  follows: 

(1)  The  function  should  show  some  initial  convexity  and  the  final 
saturation  effect  due  to  varying  sizes  of  the  address  clusterings, 
and 

(2)  It  should  link  together  T,  the  processor  busy  period,  and  S,  the 
storage  allocated,  in  a  simple  manner,  perhaps  through  a  constant. 
Finally, 

(3)  Within  the  above  framework,  we  should  find  as  simple  a  functional 
representation  as  possible. 

In  searching  for  this  analytic  function,  we  should  keep  in  mind  that 
the  chief  purpose  is  to  have  a  functional  representation  of  some  tangible 
program  properties.  One  question  confronts  us  immediately:  should  the 
representation  be  a  quantitative  one,  or  should  it  be  qualitative  one?  It 
would  be  most  satisfying  if  we  can  have  both.  But  it  is  not  to  be  and  the 
reasons  are  simple:  the  paucity  of  data,  together  with  the  nature  and  the 
manner  in  which  they  are  obtained,  preclude  a  meaningful  quantitative  repre¬ 
sentation,  due  to  the  high  degree  of  inaccuracy  of  the  data  themselves.  On 
the  other  hand,  there  are  certain  observed  characteristics  which  appear  to 
be  intrinsic  to  programs  in  general.  Therefore,  we  opt  for  a  general  model 
rather  than  one  which  only  suits  some  specific  numerical  values.  To 
solidify  the  direction  of  search,  we  would  like  to  have  an  analytic  function, 
T(S) ,  which  satisfies  the  following: 

(1)  T(0)  -  0 

(2)  lim  T(S)  -  constant 

S-WO 

(3)  T’(S)  >  0,  all  S 

(4)  there  exists  a  finite  value,  S^»  such  that  T"(SL)  ■  0 
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(5)  T"(S)  -  +  for  all  S  <  SL 

T"(S)  “  -  for  all  S  >  S^;  S  finite 

Note  that  T'  and  T"  are  first  and  second  derivatives  with  respect 
to  S. 


The  function 


T(S) 


2  2 
S  +D 


(6.2.1) 


where  K,  D  are  constants,  has  all  five  properties  as  stated. 

Let  us  consider  the  power  series  expansion  of  the  function  T(S). 

„2 


T (S)  -  K 


2  2 
S+D 


(V 

=  K  V 


i+<!>2 


„  r  2  4^6  8  ,  .  S 

=  K  [r  -r  +r  =r  +...],  where  r  «  — 


The  series  converges  to  T(S)  for  r  <  1,  i.e.,  S  <  D.  If  S  «  D,  then  a 
good  approximation  would  be 

f (S)  =  K  (|)2 


This  is  in  agreement  with  the  approximation  chosen  for  the  Lifetime 
Function  by  Belady  and  Kuehner  [42].  Specifically,  for  a  portion  of  the 
"observed"  curve,  namely  small  S,  they  have  chosen  the  following: 

f(S)  -  aSb 

where  a,  b  are  constants.  For  most  programs,  b  is  found  to  be  around  2. 
To  be  more  precise,  a  ■  a 'a"  where  a'  reflects  the  property  of  a  given 
instruction  set  and  a"  is  the  conversion  factor  from  storage  cycles  to 
real  time,  if  time  is  indeed  the  unit  used.  If  one  chooses  instead  to 
consider  the  mean  number  of  memory  references  before  a  page  fault,  called 
Mean  Head  Way  by  Saltzer  [45],  the  differences  will  merely  be  a  constant 
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conversion  factor.  Clearly,  this  approximation  is  valid  only  for  S  «  D, 
where  D  is  a  constant  influenced  by  user  style,  instruction  set  and  appli¬ 
cations,  etc.;  it  does  not  account  for  the  "saturation  effect"  discussed 
earlier,  namely,  the  QR  region  of  the  Lifetime  Function. 

6.2.3  Some  Limitations 

The  function  as  given  by  Eq.  6.2.1  does  not  give  correct  representations 
at  the  extreme  values  of  S.  According  to  the  functional  form,  T  -*■  K  as 
S  -*■  °°.  But  when  the  storage  space  is  large  enough  to  contain  the  entire 
program,  there  is  no  page  fault.  Alternatively  speaking,  the  mean  time 
between  a  page  fault,  i.e..  Lifetime,  is  infinite;  in  other  words,  the 
function  should  become  singular.  And  we  cannot  interpret  the  value  K  as 
the  total  run  time  of  the  program;  but  we  may  treat  K  as  the  order  of  the 
mean  time  between  page  fault  if  the  amount  of  storage  allocated  to  a  program 
is  very  near  its  total  size. 

Secondly,  when  S  -*  0,  dT/dS  =0.  If  we  restrict  ourselves  to  examine 
a  very  narrow  range  of  any  given  program,  at  any  given  part  of  the  program, 
the  execution  pattern  is  likely  to  be  sequential.  From  the  previous  analysis, 
in  a  strictly  sequential  addressing  pattern,  the  mean  time  between  page  fault 
is  linearly  proportional  to  the  amount  of  storage  given,  with  a  slope  inversely 
proportional  to  the  processor  data  fetching  rate  which  is  certainly  not  zero 
anywhere. 

6.3  A  Procedure  for  Curve  Fitting 

In  our  chosen  form  of  the  Lifetime  Function,  constants  K  and  D  actually 
become  parameters  in  characterizing  individual  programs  and  they  vary  from 
program  to  program.  If  the  function  is  to  be  a  useful  representation,  we 
should  be  able  to  determine  the  values  of  K  and  D  when  a  set  of  real  life 
data  (i.e. ,  measured  from  actual  program)  are  available. 

To  judge  whether  a  particular  "fit"  is  the  best  fit,  we  must  have  a 
criterion.  The  most  commonly  employed  norm  is  the  "least  square  error". 

The  procedure  can  be  summarized  as  follows: 

Suppose  f(K,  D,  S)  is  the  intended  function  and  for  each  there  is 

an  observed  value  T^.  Then: 

1.  Form  individual  error  term  as 

ei  -  Ti  -  f (K,  D,  Si) 


115 


2.  Form  Che  sum  of  error  square 

N  2 
H-Ie 

i 

»  2 
-  £  [T  -  f (K,  D,  S  )T 

i  1 

where  N  Is  Che  number  of  data  points. 

3.  Find  K  and  D  such  Chat  M  is  a  minimum. 


Step  3  is  a  generalized  statement.  In  actual  practice,  there  are  many 
ways  to  "minimize"  a  function.  The  simplest  way  to  locate  an  extreme  is  by 
setting  the  first  derivative  equal  to  zero. 

Now  consider  the  curve  fitting  problem  of: 


2  2 
S  +  D 


From  a  series  of  T^,  the  observed  values,  corresponding  to  S^,  we  would  like 
to  determine  K  and  D  in  the  least  square  sense. 

Note  that  one  of  the  parameters,  namely  D,  is  not  linear.  Therefore, 
a  common  strategy  is  by  iteration  as  follows  [46]: 

i)  To  start  the  iteration,  first  guess  the  nonlinear  parameter  D 
ii)  Find  best  fit  K,  the  linear  parameter,  in  the  usual  manner  of 


ill) 


iv) 


v) 


least  square 

Form  residual  (error) 


N  -  Si  2 

M  -  l  (T  -  K  ,  ) 

i  Sj  +  D 


Find  gradient  2 

N  Si 

9M  "  (T  -  K  — j 

3D  "  4  “  1 


)  [- 


N  K  s: 

-  Jg  -  A  K  l  [-2-^ 

i  +  D‘ 


2  '  Ti]  [,„2 


KSjD 

2  2  2 
(S^  +  D  V 

SiD 


_  2  2 
(S‘  +  D V 


Compute  new  value  of  D  by  stepping  in  the  direction  of  -(3M/3D), 
assume  step  size  h.  That  is,  D^+^  -  -  h  -|^  for  the  j-th 

step  iteration 
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vi)  Find  corresponding  new  M  which  is  •  new  local  minimum 
vii)  Repeat  steps  from  ii)  on,  until  stopping  criterion  is  met 


For  set  (i)  we  would  like  to  have  a  reasonable  guess  to  start  the 
iteration  in  the  hope  that  iteration  time  might  be  thus  shortened.  We 
shall  first  look  at  the  derivatives  of  our  function. 

f .  k_ i. _ 

S2+l>2 

dT  (S2  +  D2) • (2S)  -  2S«(S2) 

dS  .  <S2  -  D2)2 

3  2  3 

v  r2S°  +  2D  S  -  2SJ  . 

“  K  l  j  22  ‘ 

(S^  +  D V 


2KD 


2  2  2 
<S^  +  D  V 


d2T  __2  f(S2  +  D2)2  -  2S»(S2  +  D2) ♦  (2S)  , 

«S2  '  (S2  +  »V  1 

.  2K0*  ,(S2  ♦ /)  -  «s2) 

(S^  +  dV 
2  2 

ovn2  r  D  -  3S  , 

9  2KD  [  rx  J  O  J 

(S^  +  dV 


d2T 

dS2 


h-± 


At  this  point: 


S  •  2“2 


n 

(D//3) 


2  2  2 
(D  /3  +  dV 


18K  1 

16/5  D 
9  K 
8/3  D 


¥  0 

In  other  words,  the  portion  of  the  curve  around  this  point,  ST  »  — 

L  /5 

is  relatively  linear.  Therefore,  by  looking  at  the  data  points 
collectively,  the  first  guess  at  D  will  be  based  upon  the  "linear"  portion 
of  the  intended  fit. 
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In  step  (11),  for  the  linear  coefficient  of  the  least  square  best  fit, 
it  is  found  as  follows : 

_2 


T  -  K 


.2  2 
S  +  D 


For  a  given  data  pair,  i.e. ,  ■  T^,  the  "residual"  is: 


ei"Ti'K  2~2 
+  D 


The  sum  of  square  e^: 


H  -  I  £ 

-  ?  [Ti  - K  -r^2 

i  si +  D 

A  "best  fit"  would  be  the  K  such  that  M  is  minimized;  this  happens  at: 

2  2 
N  Sf  Sf 

^“'2i lTl " K 7T71 'ZT?1 


-  0 


We  have: 


N 


N  S. 


Therefore : 


I  T  -  K  L  ~2_ *  2 

i  i  s;  +  d 


N  _ 
2  T . 


K  - 


Furthermore: 


N  S1  2 
I  (~ 2~^  2' 

1  St  +  D* 


j2v|  N  S‘  , 
■  2  E  (■  2— -j)2 

dK  1  si  +  D 


(6.3.1) 


which  is  always  positive,  hence  M  is  a  minimum  when  K  is  given  by  (6.3,1), 
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Steps  (iv)  -  (vi)  are  actually  known  as  the  method  of  steepest  descent 
In  minimization.  The  detailed  procedures  are  as  follows  [46]: 

-  Given  an  objective  function  M  which  is  to  be  minimized,  search  in 
the  negative  gradient  direction  until  three  points  are  found  for 
which  the  middle  one  has  the  least  of  the  three  values  of  M.  This 
can  be  done  by  stepping  forward  in  equal  sized  steps  until  a  larger 
value  than  the  immediately  preceding  one  is  reached.  If  the  first 
step  has  this  property,  we  bisect  the  step  size  and  try  again. 


-  If  the  three  values  of  the  objective  function  are  found  to  be 

for  the  jth  iteration  where  h  is  the  step  size  and: 
-h  °  h  ... 

-  M  -  h  ~ —  ) 


then  the  new  point  where  the  new  minimum  of  is: 


where  t  is  found  by  quadratic  interpolation,  i.e.: 

_h  M(h  }  "  M-Jh 
2 

n  u  -n 


-  The  new  minimum  of  objective  function  M  for  the  (j+l)th  iteration  is: 
M^+1)  =  M(D<;1+1)) 

In  any  iterative  procedure,  a  common  problem  is  that  of  a  satisfactory 
stopping  criterion.  No  general  criterion  exists.  An  often  used  one  is 
#the  difference  between  the  values  of  two  successive  iterations  of  the  func¬ 
tion  in  question,  in  this  case,  the  objective  function  M.  Specifically,  the 
process  shall  terminate  if: 

where  o  is  a  predetermined  constant.  Not  only  the  iteration  time  depends 
on  the  choice  of  value  for  o  but  also  there  is  no  assurance  that  if  and 
when  it  finally  terminates  an  extremum  has  been  found,  even  a  local  one. 
Again,  if  the  function  is  convex,  a  global  extremum  will  be  assured. 

Another  difficulty  is  that  the  iterative  procedure  as  outlined  before  does 
not  guarantee  even  the  reduction  in  value  of  M  in  each  iteration,  even 


chough  within  each  step,  the  minimization  process,  i.e.,  the  linear  square 
best  fit  and  steepest  descent  respectively,  does  assure  minimum  in  either 
K  or  M.  In  fact,  the  total  square  error  M,  either  Increases  or  decreases, 
depending  on  the  initial  guess  of  the  value  of  D.  Recalling  that  the  proce¬ 
dure  requires  guessing  at  a  value  of  D  first  to  start  the  iterations.  Since 
ST  is  a  point  where  the  second  derivative  of  the  Lifetime  Function  vanishes, 

la 

we  use  some  "eyeball  judgement"  in  choosing  the  value  of  S.  .  According  to 

L 

our  chosen  functional  representation  of  Lifetime  Function,  S  “  D//T. 

L 

Therefore,  effectively,  we  have  guessed  at  D. 

The  problem  of  finding,  and  meeting,  the  stopping  criterion  manifested 
Itself  when  we  tried  to  apply  those  steps  for  curve  fitting,  with  a  specific 
set  of  data.  Real  life  data  is  very  scarce  and  hard  to  come  by.  We  have 
on  hand  a  set  of  data,  i.e.,  an  experiment  performed  by  Boyse  [47]  on  a 
FORTRAN  level  G  compiler  executing  in  MTS  environment  at  the  University  of 
Michigan.  Mean  time  between  page  faults,  in  milliseconds,  were  measured 
for  a  given  size  of  storage  allocation,  in  number  of  pages,  in  discrete 
steps.  The  data  is  tabulated  in  Table  6.1. 

With  some  modifications  to  the  procedures  discussed  earlier,  we  are 
able  to  carry  out  the  curve  fitting  process  satisfactorily  and  obtain 
K  -  839  and  D  *  35,  with  the  resulting  Lifetime  Function  as  the  following: 

_  §2 

T  -  839  - r  (6.3.2) 

S  +  (35) 

which  is  shown  in  Figure  6.4.  The  details  of  the  modifications  are  given 
in  the  Appendix. 


6.4  A  Linear  Approximation 

Let  us  consider  a  power  series  expansion  of  the  Lifetime  Function: 

„2 


T(S)  -  K 


2  ^  2 
S  +  D 


Recall  that  Taylor  Series  Expansion  for  function  f(s)  about  the  point 
is  given  by: 

f(s)  -  E  8j(S  -  SQ)j 


where: 


f(3)(S  ) 

aj  “  J1  j  “  0.  1.  2,  ...  . 
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Pages  la  Core 


Mid-point  (pages) 


Saaples 


Mean  Tine  Between 


5 

29 

7.5- 

S 

127 

43.6 

5 

325 

205 

5 

57 

620 

Table  6.1  Execution  Characteristics  for  FORTRAN 
Level  G  Compiler  In  MTS  Environment 


Lifetime  Function  for  FORTRAN  Level  G  Compiler  under  MTS 


*v  » 


I H: l»^»ti»iaiitMI>(Mi«liiiW>«lii.  u « 


-24i 


If  we  choose  to  expand  the  function  T(S)  around  the  most  linear  portion 


then  set  Sg  ■  *  D//T.  We  have: 

D2 


f(0)(SL)  -  K 


K 

A 


a0 


t<0><SL>  K 


0  ! 


f(1)(s ,,  -K 

L  (SJ  +  o) 


K  [- 


2D 

_/3L 


<^+D2)2 


8vT 


(2)3/2(K) 

V  V 


1  ! 


(3)3/2K 

V  V 


f(2)(S  )  ■*  0 

f(2)(SL) 
a2  *  2  ! 


Therefore,  T(S)  in  power  series  form  would  be: 

T(S)  -£  +  (|)3/2(|)(S  +  ...  ♦ 

where  R  *  remainder  terms,  with  the  radius  of  conversance  R 
n  c 


(—  -  D)  <  S  <  D 

✓7 


0,1550  <  S  <  D 


(6 


If  we  drop  Che  remainder  terms,  then  we  have  a  linear  approximation  of  the 
following: 

_  v  11/11?  n 

(6.3.4) 


T(S)  =  £  +  (|)3/2(|)(S  -  — ) 
4  4  D  ^ 


Note  that: 

1)  If  T(S)  -  0,  then 


k(£  +  (|)3/2(^)(s  -  ~>]  -  0 

V  3 

„  D  D,4, 3 


0.577D  -  2  x  0.192D 
0. 19 3D 


2)  For  S  =  0.155D,  then 


T(0. 155D)  -  K  [£  +  (|)3/2(^)(0.155D  -  0.577D)] 

..  ,1  5.21  x  0.422, 

.  K  [_ - - - ] 


=  -  0.024K 


3)  For  S  -  D,  then 

T(D)  ■  I  ||+  (1  -  0.577)] 

-  0.524K 

4)  For  S  *  ST  ■  — ,  then 

L  A 


Clearly,  as  it  stands,  (6.3.4)  cannot  have  (6.3.3)  as  the  valid  range  of 
S,  since  from  (2)  above,  we  would  obtain  a  negative  value  for  T,  which  is 
not  realistic.  Therefore,  we  have  the  following  linear  approximation, 
with  only  the  range  of  S  slightly  modified: 

T(S)  -  A  +  BS 


where : 


A 

B 


K 

“  8 

(3)3/2(K) 

V  V 


(6.3.5) 
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and: 


0.193D  <  S  <  D  . 

Some  observations: 

1)  For  a  given  program,  If  the  allocated  storage  space  Is  centering  around 
A  »  0.557D,  where  parameter  D,  a  constant.  Is  a  program  characteristic, 
then  processor  busy  period  between  page  fault,  i.e..  Lifetime  Function, 
varies  approximately  linearly  as  a  function  of  memory  apace. 

2)  For  each  individual  program,  initial  allocation  should  be  in  no  time 
less  than  about  20%  of  the  value  of  D. 

3)  To  invest,  i.e.,  to  allocate  memory  space,  beyond  D  signifies  a  decrease 
in  return;  that  is,  the  rate  of  increase  in  the  processor  busy  period 
decreases  as  a  function  of  space. 

A)  Therefore,  for  a  given  program,  0.2D  to  D  is  a  "desirable"  operational 
range  for  memory  allocation  under  space-squeezing,  page-on-demand 
environment . 

5)  If  without  additional  consideration,  it  appears  that  the  value  of  D 

alone  suffices  to  render  a  decision  on  the  memory  allocation,  for  each 
.individual  program. 

Let  us  now  consider  a  group  of  user  programs  under  paging  environment. 
Let  us  further  assume  that  we  may  use  a  linear  approximation  as  Lifetime 
Function,  then  for  each  individual  program  i,  we  have,  following  (6.3.5): 

^  *  Ai  + 

Suppose  we  have  n  user  programs  in  memory,  each  being  allocated  memory 
space  S^.  Furthermore,  let  us  assume  that: 

IS*  Total  memory  space  S 
i 

Then,  the  mean  time  between  a  page  fault,  as  far  as  the  system  is  concerned, 
is: 

T,  _  .  -  Min  {T\ (S, ) } 

(system)  ^  i  i 

If  the  total  memory  can  be  increased  to  (S^  +  AS)  and  if  we  assume 
that  the  user  programs  remain  to  be  the  same  set  as  before,  and  if  the 
extra  amount  of  memory  is  now  distributed  among  these  n  users  according 
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to  some  dividing  rule,  i.e.: 


Z  (S  +  a  (AS))  -  S  +  AS 
i-1 


where : 


Then  the  increase  in  T^  for  each  individual  program  due  to  this  extra  share 
of  memory  space  is: 

A^  =  aiBi(AS) 

Therefore,  if  the  mean  time  between  the  system  page  fault  before  the 
increment  in  memory  space  is : 


’  \  +  BISI 

and  if,  after  the  additional  memory  space  AS,  the  mean  time  between  system 
page  fault  (MTBSF)  is: 


F,+  .  -  Min  {T.  (s.  +  a  *AS) } 

(system)  i  i  i 


■  4j  +  bj(sj  *  v4s> 

then  the  increment  in  MTBSF  is: 

^(system  “  ^(system)  _  ^(system)  "  AJ  +  BJ[SJ  +  V(AS)] ~  AI  +  ®ISI 

“  (AJ  -  V  +  (BJSJ  -  BISI)  +  aJBJ(AS) 


A  +  B(AS) 


(6.3.6) 


where: 


*  -  <‘j  -  *i>  +  (»jsj  -  ®isi> 


B '  Vj 


A_ ,  A  ,  B  ,  B  ,  and  ST,  S  are  all  constants  since  we  assume  that 
I  J  1  J  i  J 

nothing  had  changed  except  for  every  program  there  is  a  proportional  increase 
in  its  share  of  the  memory  allottment.  Clearly,  AT(SySteiD)  increases  as  a 
linear  function  of  AS.  This  is  a  simplified  view  on  the  effect  of  increasing 


126 


•*>  * 


the  system  memory  capacity  on  the  overall  (i.e.,  system)  page  fault  rate 
This  linear  behavior  had  been  observed  by  Saltzer  on  the  MULTICS  system  at 
MIT  [45]. 

6.5  Allocation  Considerations 

Some  of  the  observations  made  in  the  previous  section  concern  only 
the  individual  program.  Again,  when  individual  users  competing  for  the 
limiting  resources,  system  is  the  final  arbitrator.  In  a  paged  environment, 
the  system  not  only  has  to  make  the  decisions  as  to  which  program  but  also 
the  amount  of  that  program  to  be  loaded. 

Lifetime  Function  as  discussed  here  is  an  analytic  representation  of 
the  mean  time  between  page  fault  as  a  function  of  allocated  memory  size. 

If  we  prefer  to  keep  the  processor  as  busy  as  it  can  be,  then,  naturally, 
we  would  want  to  allocate  as  much  memory  as  possible  to  a  user,  since  the 
Lifetime  Function  is  a  monotonically  increasing  one,  hence,  increasing  the 
allocated  size  always  means  an  increase  in  the  length  of  processor  busy 
period.  The  problem  is  to  determine  what  is  adequate.  Intuitively,  we  may 
tie  this  increase,  or  "gain"  with  the  derivatives  of  the  Lifetime  Function. 

A  positive  second  derivative  always  indicates  a  gain  whenever  the  allocation 
is  increased.  Consequently ,  a  negative  second  derivative  signifies  a  decrease 
in  gain  if  the  allocation  increases.  From  this  rather  informal  consideration 
it  appears  that  the  point  at  which  the  second  derivative  of  the  individual 
program's  Lifetime  Function  vanishes  would  be  the  optimum  choice  for  allo¬ 
cation.  For  a  Lifetime  Function  as  given  by  (6.2.1),  this  point  is  at: 


It  may  be  surprising  at  first  glance  since  it  does  not  relate  to  the 
other  parameter,  K.  A  little  reflection  tells  us  that  D  is  actually  the 
characteristic  of  address  clustering  (a  user  characteristic)  while  K  takes 
into  account  the  property  of  a  given  instruction  set  and  the  conversion 
factor  from  storage  cycle  to  real  time,  as  was  discussed  in  Section  6.2.2. 
Clearly,  allocation  should  be  based  upon  program  properties. 

The  question  of  selecting  which  program  to  load  can  also  be  handled 
in  like  manner  as  that  discussed  in  Chapter  5.  Again,  the  problem  is 
transformed  into  that  of  constructing  the  objective  function  using  the 
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generalized  value  concept.  The  quantity  (K/D)  should  be  a  good  candidate 
for  this  consideration.  Specifically,  we  may  state  our  linear  programming 
problem  as: 


K1  K2  Kn 

Maximize:  x,  +  =—■  x.  +  ...  +  ^  x 

V.  l  Ur.  z  u  n 

±1  n 


Subject  to:  —  (D,x.  +  D„x0  +  . . .  +  D  x  )  5  S_ 

/3  1  1  22  n  n  T 


(6.3.7) 


where  ST  is  the  total  memory  units  and  K^,  are  parameters  that  characterize 


program  x^. 


CHAPTER  VII 
Conclusions 

We  have  studied  the  operating  systems  from  a  certain  view  point.  We 
were  influenced  by  the  observation  that  the  complex  interactions  within 
the  computer  system  are  quite  similar  to  the  larger  economical  system  on 
a  national  level.  If  we  think  of  the  user  community  as  a  set  of  production 
requirements,  each  consumes  a  certain  amount  of  resources  and  perhaps,  in 
turn,  produces  commodities  for  consumption  by  the  others  within  the  society, 
then  the  analogy  is  clear.  Cast  in  this  light,  the  role  of  the  operating 
system  is  clearly  a  managerial  one.  And  therefore,  all  the  activities 
within  the  system  can  be  considered  as  cooperative  efforts  in  achieving 
the  production  goal.  The  performance  question  thus  becomes  how  well  we 
can  plan  our  production,  with  available,  but  nevertheless,  limited  resources. 
We  have  been  quite  accustomed  to  the  notion  that  performance  is  always 
equated  with  speed,  in  unit  time,  or  efficiency,  in  percentage  of  time, 
and  the  like.  We  may  pose  the  question  that  in  the  total  framework  of 
production  activities,  whether  this  is  the  necessary  and  the  only  criterion. 
It  is  not,  for  we  consider  that  this  view  is  perhaps  not  general  enough. 

For  example,  there  is  no  doubt  that  the  priority  system  has  a  reason  for 
being  in  the  computer  system.  Priority  assignment  sometimes  can  be  quite 
arbitrary  in  the  sense  that  it  has  little,  or  nothing  to  do  with  the  user 
resource  demands  as  against  the  usual  approach.  But  we  cannot  gauge  the 
loss  if  the  system  does  not  serve  this  particular  user,  out  of  no  other 
reason  than  the  concern  for  resource  utilization.  Oncd  we  have  broadened 
our  view  on  the  performance  question,  as  discussed  in  Chapter  3,  then  the 
usual  question  of  optimal  resource  allocation  can  be  considered  as  goal 
oriented  planning  (programming)  and  the  objectives  can  be  chosen  in  a  very 
general  manner. 

One  of  the  anomalies  in  the  operating  system  is  that  one  cannot  quantify 
its  design  specifications.  Each  particular  implementation  entails  its 
special  characteristics.  What  is  desirable  is  not  some  specific  implemen¬ 
tation  knowledge,  but  rather,  some  general  principles.  In  Chapter  A,  we 
have  discussed  the  ideas  of  activities  and  activity  aggregates.  This  is 
an  abstraction  on  the  modelling  of  the  operating  system.  Unlike  the  notion 
that  the  operating  system  can  be  modelled  as  a  set  of  interacting  processes, 
we  view  the  system  as  a  conglomerate  of  interdependent  activities;  inter- 
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dependent  in  the  sense  that  they  either  compete  for  resources  or  their  action 
sequences  necessarily  follow  each  other. 

Memory  is  one  of  the  most  important  resources  in  computer  systems.  By 
studying  the  memory  allocation  problem,  coupled  with  the  broadened  view  on 
performance,  a  wide  range  of  allocation  criterion  is  possible.  We  have  also 
carefully  differentiated  between  the  allocation  and  scheduling  problem;  one 
is  static  while  the  other  is  dynamic  in  nature. 

Finally,  we  consider  the  question  of  analytic  representation  of  user 
program  characteristics  under  the  paging  environment.  From  observations  on 
the  nonlinear  addressing  property,  a  possible  function,  the  Lifetime  Function, 
is  studied.  This  function  links  together  the  page  fault  rate  to  that  of 
allocated  memory  space.  In  other  words,  given  a  certain  amount  of  memory, 
the  page  fault  rate  can  be  estimated,  in  principle  at  least,  and  is  indepen¬ 
dent  of  the  page  replacement  algorithm.  It  can  certainly  be  argued  that  a 
proper  (optimum)  page  replacement  algorithm  can  improve  on  the  page  fault 
rate  over  this  fixed  Lifetime  Function  approach  for. a  given  memory  space. 

This  "proper"  algorithm  is  almost  certain  to  be  a  more  complicated  one,  while 
the  Lifetime  Function  approach  has  the  virtue  of  simplicity.  More  efforts 
are  needed  in  this  direction  in  trying  to  understand  more  about  user  program 
characteristics . 

In  summing  up,  we  have  studied  the  memory  allocation  problem  under  a 
multiprogramming  batch  environment,  with  and  without  paging.  The  study  is 
along  general  principles,  rather  than  some  specific  points.  Therefore,  the 
analyses  and  the  ideas  put  forth  in  Chapters  4,  5,  and  6  should  be  applicable 
to  specific  systems  as  well.  This  approach  is  possible,  even  natural,  after 
we  have  re-examined  the  performance  question  in  Chapter  3.  Constrained 
resource  allocation  problem  and  linear  objective  functions  lead  to  Linear 
Programming  Problems.  Its  mathematical  underpinnings  are  well  known. 
Furthermore,  we  have  taken  the  general  view  that  a  system  is  optimal  if  it 
operates  the  way  we  want  it  to  operate.  Then  the  more  usual  notion  of 
maximum  resource  utilization  is  but  a  special  case.  The  discussion  on  the 
optimization  of  the  objective  function  illuminates  a  certain  inherent  diffi¬ 
culty.  A  non-exhaust ive  approach  in  the  optimizing  process  is  therefore 
more  realistic.  We  have  also  suggested  a  way,  i.e.,  the  generalized  value 
concept,  to  quantify  the  relative  importance  of  each  individual  program. 

Once  the  aforementioned  "practical"  algorithm  for  optimizing  a  linear 
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objective  function  is  implemented  in  operating  system  modules  responsible 
for  resource  allocation  and  program  scheduling,  a  variety  of  allocation  and 
scheduling  policies  can  be  implemented  or  changed,  with  relative  ease,  by 
changing  the  rules  for  assigning  a  value  to  each  program.  This  approach  is 
a  departure  from  the  conventional  thinking. 


APPENDIX 


f 


hence : 


Carry  this  further,  we  arrive  at  the  solution: 


d  t*\  (Xt)^  -It  J  „  . 

j  !  *  j  *  0,  1,  2, 


134 


mr 

9  Jr* 


B.  Derivation  of  Eg.  (3.3.12] 


Basic  differential-difference  equation 


dP  (t) 


APn-l(t)  +  wPn+l(t>  "  <X+^>pn(t> 


for  statistically  equilibrium  case,  P'  (t)  *  0,  all  P  's  are  independent 

n  n 

of  t.  Then: 

Subject  to  the  constraints: 

P_1  -  0  pPQ  -  0 


We  have  pP^  -  XP^  =0  n  *  0 


and  pP  . .  +  XP  ,  -  (X+p)P  =0  n  >  0 

n+i  n-1  n 

The  solutions  are  straight  forward: 

n  *  0  P  =  -  P_ 

1  p  0 

n  =  1  pP2  +  XPQ  -  (X+p)P1  -  0 

pP2  +  XPQ  -  (X+p)(^)P0  *  0 

uP2  u  F0  '  ° 

X  2 

P2  *  V  \ 

Clearly  I>n  -  (i)\  -  pnP0 

where  p  -  —  is  called  load  or  utilization  factor. 


r 


Derivation  of  Eg.  (3.3.16) 

From  Eq.  (3.3.15),  we  have 

7  .  l-  (n+1)pn  +  up**1 
(i-pXi-p  ) 

Suppose  p  «  1 

L  »  p(l-NpN  +  NpN+1  -  pN)(l+p  +  p2  + 
■  p(l+p) 


•)(1+P 


N+l 


p2N+2  + 


for  p  »  1 


N+l  .  „  N+2 
7  ,  P  ~  (N+l)p  +  N p 

w,  N+l. 
(i-phi-p  ) 


„  «„N+1  .  w  N+2  N+l 
p  -  Np  -f  Np  -  P 

/i  v N+lx 
d-p)d-p  ) 


„  N+l.,  .  N+l 

p-Np  (l-p)-p 

(l-p)(l-p  ) 


*  P  +  N£Nt2.---J> 
N+2 


*  Nfi 


N+2 


N+l 


N+2 


N+l 


Suppose  that  p  -*•  1,  we  shall  consider  the  Taylor  Series  expansion  of  L 

Recall  that : 

f(x)  -  I  a.  (x-x-)k 
k-0  K  u 


where 


k  ■  1,  2,  ... 


In  the  context  of  our  problem,  it  has  the  following  form 


For  p  1,  if  we  take  the  linear  approximation,  then 


Now, 


where 


L  =  aQ  +  a^(p-l) 


/UJ,.  N+l  N+2 
r  .  p-  (N+l)p  +  Np 

L  ,  N+l  N+2 

1- p- p  +p 


L(l) 

lim  A(p) 
P*1  B(p) 


A(p) 

B(p) 

A'(P) 

A”(p) 

B'(p) 

B"(p) 


N+l  ,  „  N+2 
p  -  (N+l)p  +  Np 

,  N+l  ,  N+2 

1-  p-  p  +  p 

1-  (N+1)2pN  +  N(N+2)pN+1 

-  N(N+l)2pN_1  +  N(N+l)(N+2)pN 

'  -1-  (N+l)2pN  +  (N+2)pN+1 

■  -N(N+l)pN-1  +  (N+l)(N+2)pN 


Note  that 

A' (P)  -  ^  A(p) ,  etc. 


We  have 

a0  -  L(l) 

■  lim  A(p) 
P+1  B(p) 

A" 

"  B" 


-N(N+1)2  +  N (N+l) (N+2) 
-N(N+1)  +  (N+l) (N+2) 


ai-L'<1>±^iL 

T  Q-(N+l)pN+1+NpN+2 

1  „  nN+1  4.  nN+2 

1  -  p  -  P  +  P 

-t  A(p)  -  B(.p) 

L  C(p) 

A(p)  -  (1-  p  -PN+1  +  PN+2)[1-  (N+l)2pN  +  N(N+2)pN+1] 

B(p)  -  tp-  (N+l)pN+1+NpN+2][-l-  (N+l)pN  +  (N+2)pN+1] 

C(P)  =  (1  -  p  -  p  +p  ) 

A’"  -  N(K+l)2[-(N-l)(n-2)(N-3)pN_4  +  N(N-l) (N-2)pN~3 
+  2N(N-l)(2N-2)p2N“3  -  2N(2N+l)(2N-l)p2N"2 
+  N(N+l)(N+2) [N(N-l)(N-2)pN“3  -  N(N+1) (N-1) pN“2 

-  2N(2N+1)(2N-1)p2N_2  +  2N(2N+2)(2N+l)p2N-1J 

B"'  -  -N(N+1)  (N(N-l)(N-2)pN~3  -  2N(N+l)(2N-l)(2N-2)p2N"3 

+  2N2(2N+l)(2N-l)p2N_2]  +  (N+l)(N+2)([N(N-l)(N+l)pN_2 

-  2N(2N-l)(N+l)(]N+l)p2N"2  +  2N2(2N+2)(2N+l)p2N_1] 

C'"  -  2{-N(N+l) t(N-l)(N-2)pN"3  -  N(N-l)pN'2  -  2N(2N-1) p2N~2 
+  2N(2N+l)p2N_1]  +  (N+l) (N+2) [N (N-l) pN"2  -  N(N+l)pN_1 

-  2N(2N+l)p2N_1  +  (2N+l)(2N+2)p2N]  +  [N(N-l) (N+l) pN-2 

-  N(N+l)(N+2)pN"1)  -  (N+l) [-N(N-l)pN~2 

-  2N(N+1)(2N-1)p2N"2  +  2N(N+2)(2N+l)p2N-1] 

+  (N+2) [-N(N+l)pN_1  -  2N(N+l)(2N+l)p2N~1 

+  (2N+l)(N+2)(2N+2)p2N]> 
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fsi*  h-  i<>c  _<  ,. ,  « 


lim  C"'(p)  -  2(-(N2+N)  [N2-3N+2-N2+N-4N2+2N+4N2+2N] 


P*1 


+  (N2+3N+2) [N2-N-N2-N-4N2-2N+4N2+6N+2] 

+  [N3-N-N3-3N2-2N]  -  (N+l) l-N2+N-4N3-2N2+2N+4N3+10N2+4N] 
+  (N+2) [-N2-N-4N3-6N2-2N+4N3+14N2+14N+4]} 


-  24 [N+l] 

lim  A'”(p)  «  (N3+2N2+N) [-(N2-3N+2)(N-3)+N3-3N2+2N+8N3-12N2+4N-8N3+2N] 


P-1 


+  (N3+3N2+2N) [N3-3N2+2N-N3+N-8N3+2N+8N3+12N2+4N] 
15N4+36N3+27N2+6N 


lim  B'"(p)  *  -K(N+1)  [N3»3N2+2N-4N(N2-1)(2N-1)+8N4-2N2] 


P-1 


+  (N2+3N+2) [N3-N-(2N2+2N)(4N2-1)+8N4+12N3+4N2] 
13N4+28N3+17N2+2n 


Therefore 


a  =  lim  L' (p) 
p+1 

«  11»  A(p)  -  B(p) 
P*1  C(p) 

-  lim  A"'  -  B"’ 
p-1  C  ' " 


2N4+8N3+10N2+4N 


24 (N+l) 

2N (N+l) 2 (N+2) 
24(N+1) 2 


J2  N(N+2) 


Hence,  for  p+1 


L  *  aQ  +  a1(p-l) 


Kf  +  J2  N(N+2)(p-l) 
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Modified  Curve-Fitting  Procedures 

The  final  working  procedures  of  Chapter  6,  Section  6.3  are  as  follows: 

1)  Guess  an  initial  value  of  SL>  then  D  -  v^S^  initial  step  size 
h  ■  0. 1  *  D 


2)  Calculate  linear  coefficient  K 
I?i 

K  *  — 


*(-ii 

i  -2 


r) 


S"  +  D 


Total  Square  Error: 


M  =  E 
i 


T.  -  K  — r 

1  S2  +  D2 


Negative  gradient: 


—  =  4K  Z 
3D  J 

r  i 

A  rr 

i 

o 

S2  +  D2  1 

(s2  +  D2)2 

L 

—  - 

3)  If 


3M 

3D 


5  0.05 


then  h  *■  lOOh 

„  _  ,  3M 

D"°-h  3D 


repeat  from  step  2) ,  otherwise  continue 


4)  Minimize  M  by  method  of  steepest  descent,  i.e.,  step  off  in  the 

direction  of  -  in  equally  Bpaced  steps,  find  3  points  with  the  middle 
3D 

one  the  smallest,  using  quadratic  interpolation  to  find  new  D. 


5)  If  |m(;5+1)  -  M(J)  |  -.  J;  j 


Otherwise 
let  GRAD  - 


„<i«> .  D(i> 


0.0001  M 


(J) 


then  stop. 


reestablish  step  size 
m  n  i 


D^+1*  -  +  h  x  GRAD 

repeat  from  step  2)  on. 

This  modified  procedure  works  satisfactorily  on  our  test  problem.  With 

different  starting  values  of  S  ,  e.g.,  20,  35  and  50,  final  values  of  K,  D 

L  5 

and  M  converge  to  K  ■  839,  D  =  35,  M  =  0.6468  x  10  .  In  other  words,  we 
have,  as  a  result  of  this  curve  fitting  procedure,  the  following  Lifetime 


Function : 


2  2 
S  +  (35) 
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